Updating Application to use Core Data from previou

问题:

I'm currently upgrading an older iPhone flashcard application that uses two SQLite dbs (one with read-only questions that can only be updated by app updates, deletion of cards, addition of cards, updates to cards, and another one where user added their own custom cards) to use Core Data instead. The only property for the "Flashcard" object that distinguishes between a read only card and user added card is the "isCustom" property. Here are the steps that I believe are necessary to do this:

(First update from 2 SQLite dbs to CoreData)

1. Get all custom card entries from the user custom card db.
2. Add new Core Data object model with read only cards, and then load in user added custom cards to this model.
3. Delete old SQLite databases (custom card db and read only card db).

(Updates in the future that will already have a Core Data model)

1. Get all custom cards from the current Core Data persistent store.
2. Migrate all custom cards to new Core Data persistent store.

I just want to make sure if this is the way to go before I start designing this system from the ground up. Any tips will be greatly appreciated.

回答1:

There's no reason that you can't still maintain two Core Data stores: one read-only for your content that you ship with your application, and one that's writable for your custom entries. I do this within one of my applications, and it allows me to easily update the database I ship with each version.

I manage my two different persistent stores under separate contexts, but you can also attach multiple persistent stores to the same persistent store coordinator to have them both be on the same context.

Note that if you use the same model for your read-only Core Data persistent store, or include the read-only data in one central persistent store, you'll also need to migrate that non-custom data to the new model every time you update that. Shipping a separate read-only Core Data store with your application would let you do that migration once on your end, rather than having each one of your end users do that migration in the field on a model update.