Tech Blogs

perspectives for IT decision makers

Knowing Schema Change Between Core Data Versions

by (August 12, 2014)

Code Data Versions and Scheme Change by RapidValue

Core Data Versioning & Core Data Migration

Core Data Versioning helps you to maintain data in your app, as app evolves. We can manage ‘managed object model’ changes between different versions of the app with the help of core data versioning.

Core Data Migration is the process of transferring data from existing core data store to new managed object model. While using core data we have a persistent store. This is the core data store (usually SQLite). Persistent store can be opened only with the help of ‘managed object model’ which is used to create it. So that the new managed object model will be incompatible with the existing data store. We need to move data from existing store to our new model, for which we use migration.

For migration to happen we need old managed object model. With the help of core data versioning, we keep all the ‘managed object model’ versions that we used as app evolved. This model is known as Versioned Model. One of these managed object model version is marked as current.

The core data is able to open existing core data store with the help of managed object model version used to create it and migrate data to current version. Migration can be either automatic (light weight migration) or manual.

Based on some of the projects we have worked on, during the migration process, we faced an issue which we resolved in the following manner:

Issue Faced – A new model version was created and a new field was added to an already existing table. Pushed build with new data model. Unfortunately the newly added field was not getting populated.

Primary Reason – Above mentioned field was to be updated from the response of api ‘A’. ‘A’ was returning 304 response (we were already using other values in this api, and it was called previously). Since there is no change in the response, we left the Api unhandled.

Right Solution – In order to overcome this issue what we should have done was to make the app call a set of APIs, despite whether they are updated or not in server. For this, we should have cleared the ASIHTTP cache.

Challenges Faced – We should clear cache only if a schema change occurred between old version managed object model and new version managed object model.


Knowing Core Data Schema Changes 

If we need to know whether core data schema has been changed in current version from that of previous version, we can use below given code

NSString * filePath = [//Get file path of DB file];
NSURL *storeUrl = [NSURL fileURLWithPath:filePath];
NSDictionary *sourceMetadata = [NSPersistentStoreCoordinator metadataForPersistentStoreOfType:NSSQLiteStoreType URL:storeUrl error:nil];
NSPersistentStoreCoordinator *storeCordinator = [//Our persistantStoreCoordinator ]; //Will create new persistant store, based on new model.
NSManagedObjectModel *destinationModel = [storeCordinator managedObjectModel];
BOOL pscCompatibile = [destinationModel isConfiguration:nil compatibleWithStoreMetadata:sourceMetadata];

In case of apps that need to persist data in various versions, we need to have a versioned model. While using versioned model, knowing schema changes between model versions will become challenging at times. Use this code to simplify your work and happy coding!

If you need more information on this topic, please do write to us at

Sebin Roy

Senior Software Engineer, RapidValue Solutions


Sorry no comment yet.


24/7 Toll Free(877)-643-1850(US)

Would you like to know more about us?

  • This field is for validation purposes and should be left unchanged.
Scroll Top