Reputation: 3634
I asked a question a while back regarding SQLite migration to Core Data and was given the answer to keep Persistent Stores separate based on my need to have a "Read Only" store, and a "Custom Store":
Updating Application to use Core Data from previous double SQLite only persistent store
I'm beginning the development of this application, and at the moment I plan on creating 2 separate contexts due to the fact that I foresee the Read Only Card Object Model staying the same for future releases, while the custom model will probably change. This way I would only really have to version the custom object model, and keep shipping the application with the same ole Read only store.
Is this a smart way to go? If so, what are some of the hurdles I should look out for? If not, what would be a better alternative?
Upvotes: 0
Views: 971
Reputation: 124997
As long as the entities in the two models don't conflict with each other you can use both models together in the same context. You can use the +modelByMergingModels:
method to create a single model from two or more models at run time. Use that new model to initialize your persistent store coordinator, and add that PSC to your context.
I'm sure you can make your code work just fine with separate managed object contexts, but one of the things that's nice about Core Data is that if you set it up right, it'll manage the details of finding your objects for you. Using a single context for both your read-only data and your user data seems like a positive step toward keeping your code simple.
Upvotes: 2