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 21:30:45 +0200
Hi,
Given that I have offended at least one subscriber with my flippant
"damn", I've probably offended lots more.. sorry about that.
It was supposed to be a light hearted "hot d*mn" and wasn't supposed
to offend anybody. In future, I'll stick to most decidedly sober and
appropriate language only.
Best regards,
Frank
On 1 Oct 2007, at 18:58, Frank Reiff wrote:
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:
40publicspace.net
This email sent to email@hidden
_______________________________________________
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