Question

I’m using core data on an iPhone application. I have multiple persisntent stores that I’m switching from one to another so that only one of the stores can be active at the time. I have one managed object context and the different persistent stores are similar in data format (sqlite) and share the same managed object model.

I’m importing the data to each persistent store from a respective XML file. For the first import everything works fine, but after I remove the imported data (the persistent store and the physical file) and then re-import, core data gives me an error:

*** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'The NSManagedObject with ID:0x3c14e00 <x-coredata://6D14F11E-2EA7-4141-9BE8-53747DE6FCC6/Book/p2> has been invalidated.'

This error comes from the save: of NSManagedObjectContext. Before re-importing, i’m removing the persistent store from the persistent store coordinator and removing the physical file, so everything should be as if re-importing was done for the first time. Alos, the objects in managed object context are removed and the context is sent the reset: message (I don’t know if this is actually needed).

Could some one help me out here? How should the persistent store be switched?

I’m basically using the same logic as tutored here: http://blog.sallarp.com/iphone-core-data-uitableview-drill-down/

Thanks in advance.

Update on the goal

Thank you for your answers.

Apologies for the vagueness on my goal. I’m developing a Bible reader application that would import translations from XML to core data SQL. Currently only one translation can be in use. Currently I only have different MOC and PS for each translation since the model is the same. I do believe, however, if you say that the stack should be created as a whole. The translations have no connections between each other, so there is no actual reason for using the same stack. The only thing that could complicate this would be notes/bookmarks/etc that will reference to the active translation. The references, however, will be textual so again there is no necessary need for a shared stack.

Thank you for your input.

Answer 1

I agree with Louis, what you are doing is a dangerous design and you should be rebuilding the entire stack instead of swapping out the stores like that. Rebuilding the full stack is not a huge overhead.

Also, if you are using completely different models with completely different data objects you don’t need to remove them, you can add all of the models together into one persistent store and based on which entity you create, Core Data will do the right thing.

If you are building multiple models with the same entity then the question is why? You are not going to get any performance benefits out of it.

Update

In the situation you have described I would put all of the stores into a single persistent store coordinator and then instruct the context which store to save the entity with -assignObject:toPersistentStore:. That will eliminate the need to build up and tear down multiple Core Data stacks.

Update 2

A new stack is the entire stack. The PSC, the MOM and the MOC. You are pulling the rug out from under the Core Data stack and then expecting it to just figure out what you are doing.

What is your end goal?

Late Update

Um, so what would be an acceptable scenario for creating only the PS and MOC and using existing PSC and MOM? If I guessed, I’d say that every time I made modifications to the existing stack, it should be created anew and that if multiple stores were used, they should be introduced at the time of the construction.

The NSManagedObjectModel, NSPersistentStoreCoordinator and NSPersistentStore are tied together rather tightly so it is unclear what your goal is here. If you update your question with what you are trying to accomplish it will make answers a lot less vague.

Having multiple NSManagedObjectContext instances is normally used when you are dealing with multiple threads and a few very rare edge cases. Having multiple NSPersistentStore instances is normally used when you have data that needs to be silo’ed for one reason or another (partially read only, etc.). Those are the normal use cases.

My question still stands though, what are you trying to accomplish?

Update on goal

I’m developing a Bible reader application that would import translations from XML to core data SQL. Currently only one translation can be in use.

Ok, you do not need separate files for each translation, that is a waste. Since each translation is identified by a code (such as ASM) and name, copyright, etc. you can simply create a top level entity in your design that is called … “Translation” and the rest of the data branches from there. No multiple contexts, no switching things around, it just works.

The only time you need multiple files is if you are in a multi-document design which is not something you do on the iPhone.