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?

So I would create something like the following:

@property (readonly) NSString *uriStringRepresentation;

...

- (NSString *) uriStringRepresentation {
    return [[[self objectID] URIRepresentation] absoluteString];
}

...

And then in my search:

    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"%K in %@", 
@"uriStringRepresentation", identifiers];


Is this a good way of accomplishing my goal?

My concern with this is that although this might work at the moment, I'm 
planning to implement autosave (haven't looked into how to do this yet), and if 
a save had happened and it was previously a temporary ID, and now it's been 
changed due to the save, then I wouldn't be able to get it back again. 

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 it can handle the transition from temporary to permanent ID, then I might 
also use this in a place where I need to partially generate some of my file 
relationships before save. I could save the URIs and then be able to look them 
up in the persistent store coordinator, and replace my URI references with the 
reference object using referenceObjectForObjectID: during the save operation. 
The documentation says that newReferenceObjectForManagedObject: is called 
*after* the MOC has saved, but from what I can see, this happens *before* my 
atomic store's save: method is called, so calling referenceObjectForObjectID: 
during save of an atomic store always retrieve the permanent id. 

Any comments on whether this would be a good way of accomplishing this?

Thanks

Gideon






_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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 arch...@mail-archive.com

Reply via email to