Re: A CoreData Limitation?
Re: A CoreData Limitation?
- Subject: Re: A CoreData Limitation?
- From: Justin Fagnani <email@hidden>
- Date: Wed, 18 May 2005 18:56:24 -0700
Let me see if my Cocoa-nubile self can add anything of value here. It
seems to me like Bill is really on the right track, but I'm not sure
that everyone is getting what he is saying.
There are really two "models" in question here, thus the confusion:
the CoreData model, and the model of the data that the end-user
creates. You do not want or need to change the CoreData model based
on what the user does. You would then potentially have a different
schema for every file.
What you really want to do is model your model, so to speak. I would
have entities like Table, Column, Row, and Cell.
You con connect these with any number of relationships to balance the
ease/speed of certain operations vs data size.
The simplest configuration I can think of would be like this:
Table <-->> Column
Table <-->> Row
Row <-->> Cell
Column <-->> Cell
Deleting a Row or Column would cascade to it's Cells. You might have
to add keys to support column and row re-ordering.
In a way, this is what CoreData is already doing, so building this on
top of CoreData will probably not be as fast as if you used SQlite
yourself. You could even have nice bindings support with a properly
implement valueForKey:. However it'll much easier, with automatic
undo support, with CoreData.
I'm mostly a Java person right now, but I've implemented a lot of
similar systems. I hope I got that right and it helps.
-Justin
_______________________________________________
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