Database Reference
In-Depth Information
What happens when our application is at version 5 of its data model and a
user at version 1 decides to upgrade? Normally, we would need to provide a
mapping model for every combination of source and destination object models.
For the first couple of versions, this is not an issue. However, as we get further
away from version 1, it becomes increasingly difficult. Fortunately, it is pos-
sible to figure out a migration path and do a progressive migration .
To accomplish a progressive migration, we need to handle the migration
manually. The workflow is as follows:
1.
If the store's model is the current model, do nothing.
2.
Find a mapping model with the current store's model as its source.
3.
Migrate the data to that mapping model's destination model.
4.
Repeat starting at step 1.
Creating the Migration Method
To begin this monumental task, we will be creating a new method in the
AppDelegate. The method requires several pieces of information: the source
path, the source type (XML, SQL, and so on), and the final model. In addition,
we will pass in an error to be able to report any failures.
RecipesV3/PPRecipes/PPRAppDelegate.m
- (BOOL)progressivelyMigrateURL:(NSURL*)sourceStoreURL
ofType:(NSString*)type
toModel:(NSManagedObjectModel*)finalModel
error:(NSError**)error
{
It's a rather unwieldy method name, to be sure, but it contains all the infor-
mation we need to figure out our migration path. Since this is going to be a
recursive method, the first thing we need to do is check to see whether we
are at our goal.
RecipesV3/PPRecipes/PPRAppDelegate.m
NSDictionary *sourceMetadata =
[NSPersistentStoreCoordinator metadataForPersistentStoreOfType:type
URL:sourceStoreURL
error:error];
if (!sourceMetadata) return NO;
if ([finalModel isConfiguration:nil
compatibleWithStoreMetadata:sourceMetadata]) {
*error = nil;
return YES;
}
 
 
 
Search WWH ::




Custom Search