Re: A CoreData Limitation?
Re: A CoreData Limitation?
- Subject: Re: A CoreData Limitation?
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 17 May 2005 14:31:30 -0700
On May 17, 2005, at 1:03 PM, Arthur Schuster wrote:
I found this in another thread:
On 11.05.2005, at 20:21, Bill Bumgarner wrote:
SQLite did not support ALTER TABLE until very, very recently.
IIRC 3.1.3 -- the version that ships with Tiger -- has very
limited ALTER TABLE support, if any at all. So adding or
removing a "column" (the change may be more complicated) is not
simply a matter of writing an appropriate ALTER TABLE SQL statement.
I think this pretty much sums up my problem---if it's (nearly or
completely) impossible to for CoreData itself to change its data
model by adding or removing a column, I probably also won't be able
for me as a developer to use CoreData for storing the data of a
table view with a variable number of columns.
So I'll stay with my current ugly but working model, unless of
course someone still finds a great workaround for this.
I don't think they are related. Or, more specifically, I don't
think they should be related.
Your application is confusing the data with the model. This is, in
my experience, a mistake in architecture (and a very common one).
If the data model changes over time, that model is, in and of itself,
also data and it should be modeled as such.
That is, you need a model that encompasses the fact that the user or
application may change the "model" of the data over time.
When you say you need "variable number of columns", that does not
require that the model change as columns are added or removed. To do
so leads to very fragile documents in that every document may
potentially have a different schema. This will also make upgrading
the schema very difficult.
Instead, consider how you would model this feature.
For example, consider an application where the user can create new
descriptors for the data managed by the app. Maybe the user wants
to add a "width" attribute that can be used to add a "width" value to
the items within the store.
One approach would be to think of each new attribute as a column that
is added to the "item" table. An obvious approach, but extremely
problematic. Specifically, what if I add a "width" attribute to my
data store that has units of feet while you add a "width" attribute
with units of meters? A simplistic example -- it gets much worse if
we both use the same "word" to describe completely different
concepts, something that happens quite commonly given the ambiguities
of most languages.
In other words: as soon as the user adds a new attribute, their
data's schema is now incompatible with all other user's of the same
application. Sharing data between users or documents has now become
a very hard problem.
Instead, you want a fixed schema that can represent the variability
of the contained data.
Rethinking the above problem, a simple approach would be to create a
"NameValuePair" entity that contains a name and a value. Your "item"
entity would then have a one to many to NameValuePair instances.
This would solve the problem in that the user can add any number of
new attributes within any name/value values that they might care for.
Now, obviously, it might be desirable to be able to ask questions
like "Give me all items that have a 'width' attribute attached to
them (maybe with a specific width)?". That could certainly be
expressed with a predicate. It could also be expressed in the
model. You could create an 'AttributeName' entity and then have
'NameValuePair' have a to-one relationship to the 'AttributeName'
entity (with a to-many inverse). You could also do something
similar for the values, thus creating, effectively, a pick list type
of attribute.
This is but one possible way that this could be modeled. There are a
number of others. The bottom line is that you want your data -- all
of the data -- to be described by a model that remains fixed.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden