Re: A CoreData Limitation?
Re: A CoreData Limitation?
- Subject: Re: A CoreData Limitation?
- From: Arthur Schuster <email@hidden>
- Date: Wed, 18 May 2005 14:20:39 +0200
On 17.05.2005, at 23:31, Bill Bumgarner wrote:
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.
This is probably my problem (of understanding). Though actually, in
my current implementation, parts of the data model are indeed saved
to the file as "data" (more specifically: the columns). Without this
data, the whole data structure itself couldn't exist. The rows ask
the column controller for this (dynamic) part of the data model---
they don't really know about it before runtime; that's also why there
needs to be some sort of default set of columns.
<snipped>
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.
You mean "item" = "row" and "NameValuePair" = "cell", right?
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.
If I understood this correctly: predicate or "AttributeName" mean
"column".
The problem with the predicates would be that they are also part of
the (fixed) CoreData model. Adding or changing a column would mean
adding or changing a predicate---which is impossible, if I understood
CoreData correctly. I think the second idea you had (with
AttributeNames) is very similar to the one of Nicko van Someren (see
my answer to his post).
The only difficulty here is linking "columns" and "rows" together in
the "cells" (both have a to-many relationship to them). I think that
van Someren's "hack"---sublassing valueForKey: and setValue:forKey:
in the row entity---could be a good solution that would most closely
resemble my current model (which can be good or bad, depends on the
viewpoint).
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.
Put differently: I need to design a fixed data model (columns and
rows) that describes a dynamic data model (the cells) which is
responsible for the actual data.
Arthur Schuster.
_______________________________________________
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