Re: Ordered Sets and NSManagedObjectID
Re: Ordered Sets and NSManagedObjectID
- Subject: Re: Ordered Sets and NSManagedObjectID
- From: Robert McNally <email@hidden>
- Date: Sun, 15 May 2005 01:03:00 -0700
>On May 14, 2005, at 9:02 PM, Robert McNally wrote:
>
>>I am writing a Core Data-based application in which I am working towards a solution of the ordered-set problem-- i.e., emulating an (ordered) NSMutableArray container with a (unordered) to-many relationship. In my case, I don't wish to store each element's index as an attribute on the element itself-- I want to leave the elements untouched. Instead, I want the NSMutableArray-like subclass of NSManagedObject to remember the order of the elements and reconstruct their order upon demand after the container is fetched. The main benefit to doing things this way is so that element objects can be shared among multiple container objects.
>
>Sounds to me like a job for another entity. Just make an entity that has an index attribute, and a to-one relationship to the things you want to view in an ordered fashion.
>
>-jcr
John,
Thanks for your response. I have considered the approach you mention, and am still considering it. But it still seems that the approach I outlined would, if it works, have some advantages over the method you suggest. For one thing, with an NSMutableArray, the changing index values are implicit as items are inserted and deleted at various indexes. If only indexes are re-arranged, then only one object (the container) would need to be re-committed. For a large, persistent, ordered array under the method you suggest, inserting a new object at index 0 (for example) would require that all the other element items in the array would need to be updated with new indexes and require re-commit. NSMutableArrays, on the other hand, support fast insertions at index 0, and no other objects would need updating.
In any case, I would still like to know the "best practice" way of dealing with temporary object ID URIs is when one wants a URI to archive, and also the "best practice" way of archiving such URIs.
Regards,
Robert
--
______________________________________________________________________
Robert McNally, Arciem Engineering <http://www.arciem.com>
626/963-7760
_______________________________________________
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