"CoreData does not support persistent cross-store relationships" despite matching x-coredata ids

Question

When saving a Core Data managed object context on iOS 6.0.1 to a SQLite store, I run into a strange "CoreData does not support persistent cross-store relationships" exception. It concerns a one-to-one relationship between Quotes and AbstractSources in the model. At runtime it concerns a Quote and a Book (where Book inherits from AbstractSource. All works well in the model editor.)

I've researched similar reports and covered the reported causes:

1. I am assigning both the Quote and the Book to the same persistent store using assignObject:toPersistentStore:, so neither remains unassigned.
2. The error description shows that all "absolute" x-coredata ids start with the same prefix (e.g. "x-coredata://82B3BEB3-60F2-4912-AC80-11AAD29CFF99/", so there really seems to be one store only in use.

My questions are these:

1. Is there anything else I have to check (perhaps sg. in relation to AbstractSource, which I do not touch/control in my source? I am creating both the Quote and the Book with a call to initWithEntity:insertIntoManagedObjectContext each.)
2. I noticed that the error description also includes several "relative" x-coredata ids (of the form "x-coredata:///..."). Could it be that the absolute form is always considered as "cross-database", even if "absolute" prefixes (see example above) are the same? And if so, how could I influence any choice between "absolute" and "relative" x-coredata ids?

Thx (much) for your attention!

Answer 1

So this is what had (presumably) caused the trouble:

1. My managed object context's coordinator has to manage two persistent stores. Now the one to which I assigned Quote and Book and were I wanted them saved is reset at start-up. There was a bug in this code, which rendered this store unusable. Since a second one was available it silently took over, in this case leading to unwanted results. Lesson: I now assert that there are/remain indeed two stores after setting up the core data stack.
2. During earlier development of my Core Data model, I had renamed some of its entities in the model editor. By mistake I had only changed names, but not the entities class properties. So in effect while everything worked well in the model editor, by-then-unexpected classes were used at runtime, and therefore unexpected classes where assigned to unexpected/wrong stores as well. Lesson: I now make sure that entities names and their class properties remain in perfect sync (other circumstances permitting).

The issue is now resolved, and I've also refactored my code/model to use (non-overlapping) configurations instead of explicit assignments, which should also help going forward.

Again, thx for your attention