Learn how to use Core Data migrations in Swift to keep your data models up-to-date!
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/917-lightweight-migrations-in-core-data-tutorial
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/917-lightweight-migrations-in-core-data-tutorial
Thank you very much for this tutorial. But I’ve a question: now you don’t need to write some code in appDelegate class, right? Remember that before you had to write a dictionary which you make know the light migration?
Other question: I’ve and old project and now I’m updating it creating a new project. And the datas are taken by an SQLite file that is in project is loaded at started. If I understand well I don’t need to write nothing, right?
In relation to your first question, you don’t ever necessarily need to keep your core data stack in the AppDelegate. It’s from old sample demo code, and in practice, can lock you into a corner when your app needs to change. Just be aware that the app delegate isn’t the only place for your stack to live.
But, to answer your question, the options dictionary you had to previously create to enable migrations has been replaced in the new Core Data APIs. It’s now part of the Persistent Container Description API. If you take a look at the Persistent Store Description API docs, you’ll see that those migration options are now properties to set on an object, rather than keys in a dictionary.
And, for your second question, I’m not quite sure I understand it correctly. But, I think you’re asking that if you are moving data from an old app to a new one with a migrated version of the database, you just need to load the data, and core data will be happy? If this is the question, then, sure, you can copy any SQLite files from anywhere (including downloading from the inter webs) and load them in your app assuming that:
- The database downloaded all the files (Shared Memory, Write Ahead Log AND the Database)
- The schema inside the database exactly matches any model version you’ve included in your app.
With those two properties met, you should be able to read a database file, and load data properly once your Core Data stack has completed initialization in your app. While you don’t need to write anything, you could then update those data objects and perform normal core data operations as you go from there…
I hope this helps, apologies for the delay,
Thanks for checking out the book!
Saul
Hi, This tutorial is really spot on. Easy to follow and implement. After a calamitous evening trying to recover from doing a core data migration incorrectly, this is just what I need to put things right.
Just one thing I notice, and I’ve seen this in other situations as well.
After adding an image to the table view, I can no longer drill down to the detail view. With non image cells, I can.
Any idea what I’m doing?
Hi Saul
You said “If an app is using Core Data merely as an offline cache, when you update the app, you can simply delete and rebuild the data store”…
Are you able to point me to resources which demonstrate how to do this? I have searched far and wide (including the Core Data by Tutorials book which is otherwise excellent) and can’t find how to do this in Swift.
Thanks
Tim
If I rewrite an old app as a totally new app, and make a database in the new app with the same tables as in the old app etc, will user data transfer? (same app ID)?
Thanks
Christina
Hi,
So, if you were to copy all your previous model files and versions over to your new app, then the new app would also use this model document to initialize your core data store. You’ll need everything related to your core data model for this to work. That includes: All model files and migrated versions and all related code files for your entities.
If you were to create an entirely new app to continue where the old one left off, with an entirely new model, your new model would have to have to match your last current model exactly. That is, all the entity names would have to match, as well as the property names in each entity, as well as all the relationships between entities and the relationship names. And, each property type should match the last known type as well. All of this information together is what generates a version hash key so that core data can match up model versions. In my experience, the optionalality or default property values incidentally do not effect the version hash value. But if you have a relationship, the one-to-one or one-to-many relation does effect your version.
I hope this helps.
Hi, so this would be achieved fairly easy using the basic (NS)FileManager apis. All you would need is the location of your core data store, and you can use the removeItemAtURL method to delete the core data store. On the next access to your core data stack, the store will then reinitialize with empty tables, and you will have a fresh cache. Remember however, when deleting your core data store files that you’ll need to also delete and WAL (write ahead logs) or SHM (shared memory) files as well as your SQLITE files. This is necessary if you have write ahead logging enabled, which is now the default for Core Data SQLite usage (so likely you’ll need to delete 3 files, unless you’ve turned this mode off, explicitly).
I hope this helps!
Saul
Hi,
apologies for such a delayed response. But, can you be a little more specific to the issue you’re seeing? I am not exactly sure where you put the image. It may be that you accidentally added it to the wrong place in the view heirarchy?
Thanks,
Saul
Thanks for getting back to me Saul. “It may be that you accidentally added it to the wrong place in the view heirarchy?” – that’s exactly what I did.
I forgot to modify my question to reflect the fix.
Many thanks again
David