This question might look like it's been asked many times before, but I'm not sure I've aggregated the answer correctly. So here goes.
ObjectIDs are described by Apple (WWDC 2012 Session 214) as context-safe, thread-safe. So I spent some time converting my code to take advantage of that. However, it doesn't appear to be as context-safe as they make it sound, because as discussed here Core Data: Do child contexts ever get permanent objectIDs for newly inserted objects? and elsewhere, there is the existence of something called Permanent IDs.
With regards to this permanent ID business, I looked in NSManagedObjectContext.h:
/* Converts the object IDs of the specified objects to permanent IDs. This implementation
will convert the object ID of each managed object in the specified array to a permanent
ID. Any object in the target array with a permanent ID will be ignored; additionally,
any managed object in the array not already assigned to a store will be assigned, based on
the same rules Core Data uses for assignment during a save operation (first writable store
supporting the entity, and appropriate for the instance and its related items.) Although
the object will have a permanent ID, it will still respond positively to -isInserted until
it is saved. If an error is encountered obtaining an identifier, the return value will be
NO.
*/
- (BOOL)obtainPermanentIDsForObjects:(NSArray *)objects error:(NSError **)error NS_AVAILABLE(10_5, 3_0);
So I've been having trouble with this in my code. I have a hierarchy of NSManagedObjectContexts (say, B and C), and only 1 of them is actually linked to a persistent store (call is A). So, C is child of B, B is child of A. If I create an NSManagedObject from C, and then call obtainPermanentIDsForObjects, is it actually permanent? Because the .h file comments reads like it only looks up the hierarchy to B (first writeable store supporting the entity, and in the child-parent setup, changes are only pushed up 1 level) , not A.
Thanks in advance.