Re: A CoreData Limitation?
Re: A CoreData Limitation?
- Subject: Re: A CoreData Limitation?
- From: Nicko van Someren <email@hidden>
- Date: Tue, 17 May 2005 21:31:30 +0100
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.
Nicko
_______________________________________________
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