> I have some queries that used to look up objects based on an elementID 
> attribute, which used to be my unique identifier for objects, created when 
> the objects were inserted or loaded. I am now moving away from that and using 
> the standard managed object IDs and reference objects.
> 
> So I used to do things like for a drag and drop of objects, I would have 
> predicates like this (where the identifiers were the elementIDs of the 
> objects I was dragging):
> 
>    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"%K in %@", 
> @"elementID", identifiers];
> 
> I guess that I will now have to use a different way of referencing it, and 
> was thinking that I could create the identifiers as:
> 
>    [[[theManagedObject objectID] URIRepresentation] absoluteString]
> 
> but if I was to do that, in order to search using a predicate, I would have 
> to create a read only attribute on my managed objects that would return that 
> value, right?

No, this is going the wrong way.  The objectID is the object's identity in the 
persistent store (e.g. primary key).  You don't need to store pieces of it 
somewhere else.

NSPredicate *predicate = [NSPredicate predicateWithFormat:@"self == %@", 
myobjectid];
or
NSPredicate *predicate = [NSPredicate predicateWithFormat:@"self in %@", 
objectidarray];

> I'm sort of looking at possible alternatives like using the MOCs 
> persistentStoreCoordinator to get the managedObjectIDForURIRepresentation:, 
> and then the MOC objectWithID: method to get the actual object back, but 
> don't know if managedObjectIDForURIRepresentation: would handle the temporary 
> ID situation and potential switch to a permanent ID on save.
> 
> I see a few posts along these lines in the past, but I haven't specifically 
> seen anything that says whether any of the methods will cope with looking up 
> a temporary URI, if it has now been turned into a permanent one.


If you stash a temporary URIRepresentation from an unsaved newly inserted 
object externally, like in the pasteboard, then no these methods won't track 
the switch to a permanent ID.  Of course, passing around IDs to objects that 
don't exist in the persistent store yet is juggling fire.  Those objects only 
exist in the MOC in which they were inserted until save, so nobody else can 
actually use their IDs yet.

If you need a permanent ID immediately, you can call 
-obtainPermanentIDsForObjects:error: on the NSManagedObjectContext

- Ben



_______________________________________________

Cocoa-dev mailing list ([email protected])

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to