Re: Best practice for Core Data "ordered" NSArray problem?
Re: Best practice for Core Data "ordered" NSArray problem?
- Subject: Re: Best practice for Core Data "ordered" NSArray problem?
- From: Frank Reiff <email@hidden>
- Date: Mon, 1 Oct 2007 18:58:01 +0200
Hi,
Thanks for your comments. Hand-coding is the only way then..
Of course, Core Data is neither the first nor the only object
relational mapping tool and the ordering problem is the same for all
implementations.
In my previous job, I used the Hibernate (open source Java) framework
and that had a very elegant way of doing this; when you have a set,
you define your attribute as a java.util.Set and if you have an
array, you define it as a java.util.List. In the case of a list, you
can define the mapping in a variety of ways (including the lame "I'm
a set impersonating a list" mode of Core Data). The most obvious one
is to simply tell Hibernate what the order-by-attribute field is and
it does the rest.. sounds simple enough? If you are really worried
about performance (say you have a large list), you do a bit of
dynamic configuration, plug in your own policy/ strategy class and
you're done.
It mystifies me why Apple can't do the same thing. In fact I was so
SURE that this was merely an oversight (not ready in time) in Tiger
and that it would be the brand new ueber-feature of Core Data in
Leopard... looks like I'm wrong again..
Seriously, it's possible to do this generically. No it won't perform
miracles performance-wise, but on today's machines it should scale to
a couple of thousand records without becoming noticeably slow. If
Java can do it, so can Cocoa.
For my particular example, nothing else but an actual array will do:
I'm storing the order in which particular operations are to be
carried out.
In my humble opinion, arrays (or rather ordered lists) are not a sign
of bad design; they are a common feature of many programming tasks
and not supporting them directly is a sign of an incomplete
framework, not faulty thinking on the part of the framework users.
It is Apple who have got it wrong. They seem to have started with the
relational database and then build an object model on top; kind of a
"relational object mapping" framework rather than a "object
relational mapping" framework. At least concerning this particular
feature.
Gives us arrays, damn it!
Best regards,
Frank
The basic fact is that an array is an array and a set is a set
Sure,
the implementation could vary, depending on performance
constraints. What
he (and others) have asked for is any solution (or reference to a
solution).
A lot of us would like to see it. I haven't tackled core data or
BigTen
yet, so I don't know what is involved. I just know I'm going to
have to
crack that nut sometime soon. Fortunately, my current stuff is
mostly in
the small array ( <100 ) category.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden