Re: Ordered Core Data
Re: Ordered Core Data
- Subject: Re: Ordered Core Data
- From: SA Dev <email@hidden>
- Date: Tue, 14 Jun 2005 09:57:49 -0400
One solution I'm toying with on the insertion-at-beginning-
of-10,000-items problem is, on awakeFromInsert, set the index to -1.
On save, if there're any set to -1, I reorder all, starting the -1's
at 0. It isn't pretty and it's still just an idea for now, but it's
one I'm toying with. Unfortunately, one problem that jumps out at me
is what to do about a reverse-order sort. It's even uglier (in my
mind) to find the highest-number++. Again, just a first thought. I've
written 0 lines of code to attempt this so far.
Maybe if someone here beats me to trying it out, they could let us
all know how it works. Admittedly, it might be a total waste of time,
but then so are most things I try ... ;-)
I agree with Johnny, however. An ordered collection mechanism that
works seamlessly with Core Data and Cocoa Bindings would be a hunk of
solid gold for many developers. It's also very likely a pipe dream
(at least for 10.4), given the relational database issues Oscar
mentions. I imagine it would take a pretty big change to Cocoa and
Core Data which is too late to change for Tiger ...
Again, I may be talking out of my butt, being completely wrong
about everything I just said (I defer to the list on that issue), but
this *is* a pretty big speed bump that seems like it wants to be
simple. ;-)
On Jun 14, 2005, at 9:19 AM, Óscar Morales Vivó wrote:
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:
40silentalcove.net
This email sent to email@hidden
_______________________________________________
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