Database Reference
In-Depth Information
Chapter 6: Versioning and
Migration
By Saul Mora
You've seen how to design your data model and
NSManagedObject
subclasses in your
Core Data apps. During app development, thorough testing can help iron out the
data model well before shipping. However, changes in app usage, design or
features after an app's release will inevitably lead to changes in the data model.
What do you do then?
You can't predict the future, but with Core Data, you can
migrate
toward the future
with every new release of your app. The migration process will update data created
with a previous version of the data model to match the current data model.
This chapter discusses the many aspects of Core Data migrations by walking you
through the evolution of a note-taking app's data model. You'll start with a simple
app with only a single entity in its data model. As you add more features and data
to the app, the migrations you do in this chapter will become progressively more
complex.
Let the journey begin!
When to migrate
When is a migration necessary? The easiest answer to this common question is
“when you need to make changes to the data model.”
However, there are some cases in which you can avoid a migration. If an app is
using Core Data merely as an offline cache, then when you update the app, you can
simply delete and rebuild the data store. This is only possible if the source of truth
for your user's data isn't in the data store. In all other cases, you'll need to
safeguard your user's data.
That said, any time it's impossible to implement a design change or feature request
without changing the data model, you'll need to create a new version of the data
model and provide a migration path.
