what's the 'proper' way to use NSManagedObjectContext's objectWithID:

Question

the docs state:

...This method always returns an object. The data in the persistent store represented by objectID is assumed to exist—if it does not, the returned object throws an exception when you access any property (that is, when the fault is fired). The benefit of this behavior is that it allows you to create and use faults, then create the underlying rows later or in a separate context.

and in Apple's 'Core Recipes' sample app the result of the method is used to populate an NSFetchRequest, and the request's result is then used, with comments to that effect:

 // first get the object into the context
 Recipe *recipeFault = (Recipe *)[context objectWithID:objectID];

 // this only creates a fault, which may NOT resolve to an object (for example, if the ID is for
 // an objec that has been deleted already):  create a fetch request to get the object for real
 NSFetchRequest *request = [[[NSFetchRequest alloc] init] autorelease];
 [request setEntity: [NSEntityDescription entityForName:@"Recipe" inManagedObjectContext:context]];
 NSPredicate *predicate = [NSPredicate predicateWithFormat: @"(self == %@)", recipeFault];
                    [request setPredicate: predicate];

I have seen many examples (other's code, and apple's 'iClass') where the result from objectWithID is used directly - meaning, its properties are accessed and merrily processed along.

Should objectWithID always be treated as a 'maybe-this-exists' object?

I'm asking because I've just run into this and hadn't been fetching against its existence.

Philous

Answer 1

What the Apple documentation is telling you is not to assume that the object exists is the persistent store, just because an object is returned.

You can treat it as though it does, accessing its properties and so on, because in the background Core Data will access the data store to service your request. However, if the object doesn't exist in the store, you'll get an exception.

Here's Apple's documentation explaining faults (which is what objectWithID: is returning to you).

Cawnpore

i guess what i'm not understanding is, then, if it somehow 'better' or 'more proper' to do the fetchRequest, using the object returned to find out if it exists, or is that exactly the same as just trying to access its properties, and getting back an exception because the object does not exist? is the latter one, a kind of shortcut, or is it ill-advised? – Philous

The answer is "it depends". If you're coding for a situation where you know the object will exist, for example where the user has no capacity to delete the object, then go ahead. If it may not exist, then you'll have to do the fetch request, or catch the exception. Which is preferable? I guess that's somewhat a question of style. I'd probably lean towards the fetch request. – Cawnpore

Answer 2

I found this article Safely fetching an NSManagedObject by URI to contain a nice all in one method for grabbing an object using objectWithID: but if it's found to be a fault, to go ahead and fetch it. The method detailed goes a bit further in dealing with object URIs, but the core technique presented is a useful extension to the discussion in this question.

Lugworm