Strictly speaking this isn’t a post about core data, honest. It’s ACTUALLY a post about how iPhone applications are deployed and updated. My shipped application contained two data models, my new application also contains two data models. One of the new versions data models is an old one renamed and another is entirely new. For some ridiculous reason I thought if I deleted something from my applications bundle it would be similarly deleted on the iPhone. That’s not the case. Thus the application ends up with 4 data models. This causes problems as the code I previously posted, cribbed from elsewhere in part, will happily migrate backwards if it finds a suitable model. I’d not thought of this as a strict problem if I was in control of what models were present, it seems I am not though.
UPDATE: After seeing some discussions about this issue and people saying it’s how XCode pushes out the updates I tested a bit more. XCode only pushes out files that have changed to ensure a quick testing cycle, it does not currently delete files. To confirm this I built an ad-hoc ipa file and installed that on my phone with iTunes. The files are indeed deleted. Therefore this is potentially a bug with XCode, it should delete files that are no longer in the bundle even if it isn’t pushing out a full update like iTunes does. It can take shortcuts, sure it has to I mean imagine testing something like Inifinity Blade any other way?, but should really ape the real world as much as possible and therefore should delete files.
End of
Of course you shouldn’t delete data models from your application after it’s deployed as you cannot dictate that somebody will upgrade to each release of your app. If the data model really was deleted from your bundle the user would be stuck as the software could not open the database to migrate.
There’s an argument to be made there, I am sure, for not using Core Data on simple or incredibly dynamic projects but that could be one for another day.
I do like the code I have got though and will not be abandoning it as it’s lightweight in terms of memory. Much more so than the other options. The use of NSOperations pushed into a queue as the migrations procede gives it remarkable power and flexibility too. There is plenty that can be done inside the migration loop to ensure it proceeds forwards and not backwards.