views:

21

answers:

1

Using Lightweight Migrations for my Core Data data model. Each update has gone smoothly…in the simulator.

On my device, I had not gone through each migration one-by-one. For example, my device had version 3, and I was on version 5. On the simulator, I went from 3 to 4 and then from 4 to 5, but when the device attempted to go from 3 to 5, it crashed with the standard "Can't find model for source store" error.

This would seem to make updating my application impossible if I were to depend on lightweight migrations (i.e. users couldn't skip an update to my app).

Is this the case, or is it likely I'm doing something else wrong?

+1  A: 

Lightweight migrations are intended to be accumulative. This is especially true if you don't use formal versioning.

I always tell clients that lightweight migration is intended largely for development purposes. You're counting on a piece of software being able to puzzle out the changes between versions. The smaller and simpler the changes the better the software can manage. At some point the change become to complex for the software to handle.

Without formal versioning you can in principle you skip a "version" as long as the software can figure out the changes. In practice, the migration software is easily confused and will break if you make any substantial changes.

For deployment, you should always plan on using "full-weight" versioned migration. This is especially true if you envision many updates. Do you expect the software to be able to handle a migration from version 1 to version 5 or higher as well as any between any two or more versions in between?

Remember as well that the previous model file has to be present for any migration to work. If you intend to skip versions, formal or otherwise, you have to retain all the model files for all the previous versions you want to migrate. If your update for version 5 does not provide or retain the model for version 3, you can't perform any migration of the existing store. In practice, this means shipping each version with all previous versions' model files. It's usually easier and safer to upgrade in series and end users are used to doing so.

It's really impossible to tell what your actual problem is in this case without looking at the models in detail. It could be a simple as the migration being to complex for the lightweight migration software to handle. The software can't understand how version 5 maps onto version 3.

TechZen
Essentially, I added a text field to an Entity in version 4, and a numeric field in version 5 to the same entity. Neither field is required. It seems simple enough, and I *have* been creating new versions each time I make a change. At any rate, it sounds like Lightweight migration isn't predictable enough to use in production
davetron5000
I wouldn't recommend using it in release. You're counting a automatic code generation to make runtime operational coding decisions with no oversight. If it makes an error, you and your users are screwed. It's a time saving tool for development if you have a large existing database but you can gain a lot of security by spending a little dev time making a formal migration in release.
TechZen