Re: Ordered Core Data
Re: Ordered Core Data
- Subject: Re: Ordered Core Data
- From: Óscar Morales Vivó <email@hidden>
- Date: Tue, 14 Jun 2005 09:19:51 -0400
It all boils down to the fact that the relational database model
doesn't lend itself nicely to ordered collections of instances of
entities with insertion and removal.
It's not a core data problem. It's a relational database problem.
You're going to find the same issues on any other RDB. I know I have.
Usually it means you should think if that is really the right design
to go. And if you really, really, really have to do it, then your
life sucks a little more and you have to do it manually.
If the main part of your application's data model has those
characteristics, maybe you should think about not using Core Data, or
you can just go and implement the manual indexing which from what
I've heard about the performance of SQLite shouldn't be that bad.
Hope that helps.
Oscar Morales Vivo
On Jun 14, 2005, at 09:04 , Johnny Deadman wrote:
I am getting a bit tired of this apparently deliberate obfuscation.
The problem here, and it is a huge one, is that there is not a
managed-object friendly version of NSArray, and it is a gaping hole
in the implementation of CoreData. ***There is simply no
transparent way of representing an ordered collection of arbitrary
managed objects.***
It is *obviously* not as simple as getting/setting an index
variable which is why I find this kind of response so annoying.
Let us assume we have 10,000 objects, each with an index variable.
We want to insert an object at the beginning.
We must now riffle down through our ordered collection and
increment the index variable for all 10,000 objects. Of course we
can start with indices 100 apart or whatever but it's a miserable
way to have to think.
There are ways around this, obviously, but they *all* involve
either (a) rolling your own datastructures or (b) creating
NSMutableArrays on the fly as temporary ivars in a managed object,
with code to unroll them into indexed sets on save.
As for (a) it is ridiculous that in a IDE like Cocoa, a user should
have to write their own black/red tree implementation simply to be
able to preserve the order of a collection of arbitrary elements (I
soon found that linked lists weren't nearly fast enough).
As for (b) it is obviously a kludge, and every time I raise it as a
possibility I am warned off.
This single lacuna has caused me endless headaches and I still have
not had a really good solution proposed.
On 12-Jun-05, at 8:47 PM, mmalcolm crawford wrote:
In that case, I still don't think there should be a significant
(compared to the rest of the application) overhead. Would you be
doing anything more than getting and setting the index instance
variable?
_______________________________________________
MacOSX-dev mailing list
email@hidden
http://www.omnigroup.com/mailman/listinfo/macosx-dev
_______________________________________________
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