Re: A CoreData Limitation?
Re: A CoreData Limitation?
- Subject: Re: A CoreData Limitation?
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 17 May 2005 23:59:03 -0700
Nicko van Someren wrote:
On 17 May 2005, at 21:16, Arthur Schuster wrote:
On 17.05.2005, at 21:40, Nicko van Someren wrote:
So what you seem to be saying is that you have a set of rows and
each row has a set of cells which may or may not need to be
collected together in columns. Sounds like you need to have
entities called Row, Column and Cell, with Rows having a to-many
relationship to Cells, Columns having a to-many relationship with
Cells and Cells each having a relationship back to a single Row
and Column. Then you make the Row object a custom subclass of
NSManageObject and implement a custom implementation of various
bits of key-value coding so that valueForKey: @"foo" actually
does a fetch from the set of cells with a predicate of
cell.column.name == "foo" and insertion with setValue:forKey:
does the right thing too. You'll probably want to do something
observing too. With that in place you should just be able to
bind away and it will work.
This might very well be the answer. I'll think about it (I should
to go to bed now). Although there's one thing I'm not sure about
with this model: every row still should have the same columns
(number and type), and if I add or delete one, all the rows should
reflect this change. Is this really considered here, or am I not
yet fully understanding all this?
What do you want to fill the new cells with when you add a new
column? I suggest that you simply tweak the valueForKey: method so
that if the key is a valid column but the row does not have a cell
in that column it returns a default value based on the column key.
Please don't do that. It will end badly.
If you need derived values, implement a getter that returns the set
of objects desired. For example:
- (NSSet *) derivedFooStuff;
The above method is completely compatible with KVC (valueForKey:
anyway -- you'll need to implement setDerivedFooStuff: or the
mutableset KVC stuff for mutating the value). Simply ask for the
key "derivedFooStuff" and that method's result value will be returned.
Derived and transient attributes can appear in the model and,
therefore, can also be tracked for purposes of undo/redo.
You can also use a fetched property to create an informal
relationship between one entity and another.
But, in the end, this is still sounds like a problem that is largely
just a matter of coming up with an appropriate fixed model that is
flexible enough to represent the data as desired.
Back to KVC/KVO for a moment:
Overriding KVC in NSManagedObject subclasses is extremely
dangerous. Managed Objects -- like all of Core Data -- rely heavily
upon KVC and KVO behaving as advertised by the Foundation.
Furthermore, Managed objects heavily optimize the interaction between
KVC/KVO and the Managed Object Context (and other classes) to manage
all state, including undo/redo, validation, and behaviors related to
saving/refreshing data. If you change the behavior of KVC/KVO, it
is very likely going to break Core Data's ability to manage the
object correctly. This will lead to amazingly difficult problems to
debug.
This isn't really a limitation. As mentioned above, adding KVC
compliant derived attributes is not difficult.
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