views:

94

answers:

1

I am creating an app with a database of information that needs to be pre-filled. This data will change in future versions. In the same database, I also need to store user editable information since that user edited data directly relates to the pre-filled data.

My question is, if I'm pre-filling the database by creating a duplicate data model in a second app and copying over the core data file before release, how would I handle updates to that data in future versions of the app without destroying the user's existing data? Do the core data migration methods handle this, or must I write custom methods to programatically handle the merge at first app launch?

+1  A: 

Depending on your data model, you can create two separate persistent files, one writable and one read only. You can then add both files to the NSPersistentStoreCoordinator and reach both of them together. You can then replace the read only file on future upgrades.

However this depends on how intertwined the two halves of the data are. If they are too tightly coupled then you will most likely have to do it the hard way; on future upgrades, purge the old data and copy the new objects over one by one.

Marcus S. Zarra
Thanks! This makes things clearer for me. Splitting the persistent files sounds like the most ideal solution.One followup question though. The writable entities have several "one to many" and "many to many" relationships to the read only entities. If I delete items in the read only stores, will the writable entity then point to null instead of one of the values from the read only entity that existed in a previous version?
Cuzog