40

My app uses Core Data (with some help of Magical Record) and is rather heavily multithreaded using NSOperation.

Of course I am very careful to only pass around NSManagedObjectID between threads/operations.

Now, to get back to the corresponding managed object in an operation, I use -existingObjectWithID:error: thus:

Collection *owner = (Collection *)[localContext existingObjectWithID:self.containerId error:&error];

But what I get back is nil and error says this is an error #13300: NSManagedObjectReferentialIntegrityError.

Here is what the documentation says about this error:

NSManagedObjectReferentialIntegrityError
Error code to denote an attempt to fire a fault pointing to an object that does not exist.
The store is accessible, but the object corresponding to the fault cannot be found.

Which is not true in my case: that object exists. Indeed, If I iterate through all instances of that Collection entity with an NSFetchRequest, I find it among them, and its NSManagedObjectID is exactly the one I passed to -existingObjectWithID:error:.

Moreover, if I use -objectWithID: instead, I get a correct object back just fine.

So there is something I'm missing. Here are a few additional observations/questions:

  • "an object that does not exist": what it the meaning of "exist" in that sentence? "exist" where? It definitely "exists" in my Core Data store at that point.
  • "the object corresponding to the fault cannot be found": what it the meaning of "found" in that sentence? "found" where? It definitely "be found" in my Core Data store at that point.

So maybe I am missing something regarding what existingObjectWithID:error: does? The documentation says:

If there is a managed object with the given ID already registered in the context, that object is returned directly; otherwise the corresponding object is faulted into the context.
[...]
Unlike objectWithID:, this method never returns a fault.

This doesn't help my issue. I don't mind getting my object fully faulted, and not a fault. In fact, any fault within it will fire on the next code line when I access the object properties.

  • What would be a realistic scenario leading to an NSManagedObjectReferentialIntegrityError?

Thanks for any enlightenment.

Jean-Denis Muys
  • 6,772
  • 7
  • 45
  • 71
  • 2
    Did you ever figure this out? I'm getting the same issue and my object definitely is there and the save operation is running, but it only happens sporadically. – Adam Apr 16 '13 at 06:38

5 Answers5

40

The problem is that NSManagedObjectID you pass is temporary. You can check it by calling NSManagedObjectID's isTemporaryID method. From docs:

Returns a Boolean value that indicates whether the receiver is temporary.

Most object IDs return NO. New objects inserted into a managed object context are assigned a temporary ID which is replaced with a permanent one once the object gets saved to a persistent store.

You should first save your changes to persistent store, only then get a permanent ID to pass to other context.

Alexey Kozhevnikov
  • 4,249
  • 1
  • 21
  • 29
8

When you're using multiple contexts, you need to make sure you save context A before passing a managed object ID from context A to another context B. Only after the save completes will that object be accessible from context B.

-objectWithID: will always return a non-nil object, but it will throw an exception once you start using it if there's no backing object in the store. -existingObjectWithID:error: will actually run some SQL and do I/O if that object isn't already registered with the context it's used on.

Daniel Eggert
  • 6,665
  • 2
  • 25
  • 41
  • 3
    That's not it: when I use `-objectWithID:`, I get the correct object (as I wrote): I can use it, access it properties, its relations, everything. And indeed, the context in which it was created just previously was saved. Yet, `-existingObjectWithID:error:` still fails with error 133000. – Jean-Denis Muys Dec 27 '11 at 16:53
  • Sounds really strange. Do both contexts share the same NSPersistentStoreCoordinator? – Daniel Eggert Dec 28 '11 at 13:07
  • 1
    I "solved" this by doing a reset on the managedObjectContext. Surely not ideal, so I look forward to hearing other solutions :-) – niklassaers Feb 13 '12 at 14:30
  • 7
    what do you mean on "doing a reset on the managedObjectContext."? – Peter Lapisu Aug 13 '12 at 15:27
2

NSManagedObjectReferentialIntegrityError = 133000

NSManagedObjectReferentialIntegrityError Error code to denote an attempt to fire a fault pointing to an object that does not exist. The store is accessible, but the object corresponding to the fault cannot be found. Available in Mac OS X v10.4 and later. Declared in CoreDataErrors.h.

See this documentation.

This tutorial might be helpful to you.

So the probable reason is you are trying to fetch the object which is non existing. This happens generally when you try to create an objectid for a non existing object. The objectid will be returned to you and when try to get the object with this objectId you are thrown this exception.

Madhup Singh Yadav
  • 8,110
  • 7
  • 51
  • 84
0

I have found them while dealing with a NSManagedObjectContextDidSave notification. Many of the objects that another context had deleted couldn't be fetched because (Duh!) they had been deleted! However some of the deleted objects showed up just fine, like the ones I had already faulted in the current context.

You could have a similar issue -- the objects you can find when you iterate the store may have been faulted into that context before they got deleted and you either are not merging changes back to that context, or just haven't quite yet merged.

Stripes
  • 4,161
  • 2
  • 25
  • 29
0

I encountered this issue, even though the objectID was not temporary. This was because I foolishly forgot to set the parent on the child MOC.

childManagedObjectContext.parent = managedObjectContext

vomi
  • 993
  • 8
  • 18