Migrating a many-to-many relationship to a join table in Core Data

Question

I've got an iPhone app that uses many-to-many relationships to link tags and notes together. I'm currently using Core Data's "Relationships" feature to accomplish this, but would like to migrate to using a join table instead.

Here's my challenge: I'd like to migrate from the old model to the join-table model, and I need to figure out how to perform that data migration.

Are there any good examples of how to do this?

Update: I'm clarifying my question here to help out with what's going on here: I want to try using Simperium to support our app, but Simperium doesn't support many-to-many relationships (!).

As an example of what I'm trying to do, let's use the iPhoneCoreDataRecipes app as an example.

Here's what my Core Data scheme currently resembles:

...and here's what I'm transitioning to:

How do I get from one to the other, and bring the data with me?

Apple's documentation for Core Data Migration is notoriously sparse, and I don't see any useful walkthroughs for using an NSEntityMapping or NSMigrationManager subclass to get the job done.

Tigrinya

How does simperium get the data from your model? Can't you just fake this layout by adding some categories to Recipe and Ingredient? – Schober

what do you mean "categories"? – Tigrinya

Simperium works by taking the entities and syncing them with their servers. Problem is, it only gets attributes, one-to-one, and one-to-many relationships, because the many-to-many relationships don't work with Simperium at the moment. – Tigrinya

with an objective c category, you can add methods, and therefore fake properties, to objects. Simperium looks at your data through your entities (and not by looking at the backing (sqlite) store?). So you can add a method(/property) recipeIngredient, which would appear to Simperium to link to a join table, while in fact it's just a different view on your multi-multi link (which is in fact implemented as a join table, after all). – Schober

You will need to find out how exactly Simperium does its work when it looks at your entities. There are various approaches they could have implemented. Do you supply the model, or does their code find it out automagically, if so: how? etc etc. – Schober

@mvds, I feel like your comments on categories are really onto something here, but I can't quite visualize it -- would I create a Category called RecipeIngredient? Do I add the (RecipeIngredient) category to the Recipe and Ingredient entities? (Sorry if these are basic questions; this migration issue is a new thing for me...) – Tigrinya

ok I'll elaborate a bit more in a real answer... – Schober

Answer 1

Here is the basic process:

1. Create a versioned copy of the Data Model. (Select the Model, then Editor->Add Model Version)

2. Make your changes to the new copy of the data model

3. Mark the copy of the new data model as the current version. (Click the top level xcdatamodel item, then in the file inspector set the "Current" entry under "Versioned Data Model" section to the new data model you created in step 1.

4. Update your model objects to add the RecipeIngredient entity. Also replace the ingredients and recipes relationships on Recipe and Ingredient entities with new relationships you created in step 2 to the RecipeIngredient Entity. (Both entities get this relation added. I called mine recipeIngredients) Obviously wherever you create the relation from ingredient to recipe in the old code, you'll now need to create a RecipeIngredient object.. but that's beyond the scope of this answer.

5. Add a new Mapping between the models (File->New File...->(Core Data section)->Mapping Model. This will auto-generate several mappings for you. RecipeToRecipe, IngredientToIngredient and RecipeIngredient.

6. Delete the RecipeIngredient Mapping. Also delete the recipeIngredient relation mappings it gives you for RecipeToRecipe and IngredientToRecipe (or whatever you called them in step 2).

7. Drag the RecipeToRecipe Mapping to be last in the list of Mapping Rules. (This is important so that we're sure the Ingredients are migrated before the Recipes so that we can link them up when we're migrating recipes.) The migration will go in order of the migration rule list.

8. Set a Custom Policy for the RecipeToRecipe mapping "DDCDRecipeMigrationPolicy" (This will override the automatic migration of the Recipes objects and give us a hook where we can perform the mapping logic.

9. Create DDCDRecipeMigrationPolicy by subclassing NSEntityMigrationPolicy for Recipes to override createDestinationInstancesForSourceInstance (See Code Below). This will be called once for Each Recipe, which will let us create the Recipe object, and also the related RecipeIngredient objects which will link it to Ingredient. We'll just let Ingredient be auto migrated by the mapping rule that Xcode auto create for us in step 5.

10. Wherever you create your persistent object store (probably AppDelegate), ensure you set the user dictionary to auto-migrate the data model:

if (![__persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType 
      configuration:nil 
      URL:storeURL 
      options:[NSDictionary dictionaryWithObjectsAndKeys:[NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption,  nil] 
      error:&error])
{
}

Subclass NSEntityMigrationPolicy for Recipes

#import <CoreData/CoreData.h>
@interface DDCDRecipeMigrationPolicy : NSEntityMigrationPolicy
@end

*Override createDestinationInstancesForSourceInstance in DDCDRecipeMigrationPolicy.m *

- (BOOL)createDestinationInstancesForSourceInstance:(NSManagedObject *)sInstance entityMapping:(NSEntityMapping *)mapping manager:(NSMigrationManager *)manager error:(NSError **)error
{

    NSLog(@"createDestinationInstancesForSourceInstance : %@", sInstance.entity.name);

   //We have to create the recipe since we overrode this method. 
   //It's called once for each Recipe.  
    NSManagedObject *newRecipe = [NSEntityDescription insertNewObjectForEntityForName:@"Recipe" inManagedObjectContext:[manager destinationContext]];
    [newRecipe setValue:[sInstance valueForKey:@"name"] forKey:@"name"];
    [newRecipe setValue:[sInstance valueForKey:@"overview"] forKey:@"overview"];
    [newRecipe setValue:[sInstance valueForKey:@"instructions"] forKey:@"instructions"];

    for (NSManagedObject *oldIngredient in (NSSet *) [sInstance valueForKey:@"ingredients"])
    {
        NSFetchRequest *fetchByIngredientName = [NSFetchRequest fetchRequestWithEntityName:@"Ingredient"];
        fetchByIngredientName.predicate = [NSPredicate predicateWithFormat:@"name = %@",[oldIngredient valueForKey:@"name"]];

        //Find the Ingredient in the new Datamodel.  NOTE!!!  This only works if this is the second entity migrated.
         NSArray *newIngredientArray = [[manager destinationContext] executeFetchRequest:fetchByIngredientName error:error];

        if (newIngredientArray.count == 1)
        {
             //Create an intersection record. 
            NSManagedObject *newIngredient = [newIngredientArray objectAtIndex:0];
            NSManagedObject *newRecipeIngredient = [NSEntityDescription insertNewObjectForEntityForName:@"RecipeIngredient" inManagedObjectContext:[manager destinationContext]];
            [newRecipeIngredient setValue:newIngredient forKey:@"ingredient"];
            [newRecipeIngredient setValue:newRecipe forKey:@"recipe"];
             NSLog(@"Adding migrated Ingredient : %@ to New Recipe %@", [newIngredient valueForKey:@"name"], [newRecipe valueForKey:@"name"]);
        }


    }

    return YES;
}

I'd post a picture of the setup in Xcode and the sample Xcode project, but I don't seem to have any reputation points on stack overflow yet... so it won't let me. I'll post this to my blog as well. bingosabi.wordpress.com/.

Also note that the Xcode Core Data model mapping stuff is a bit flaky and occasionally needs a "clean", good Xcode rester, simulator bounce or all of the above get it working.

Unscrew

I hv a little doubt here, it seems you are setting relations in this code as well while using: [newRecipeIngredient setValue:newRecipe forKey:@"recipe"]; isnt this method supposed to only create instances, and not set relations? – Luiseluiza

Great answer! According to the docs, since you are not calling super you need to manually call: [manager associateSourceInstance:sInstance withDestinationInstance:newRecipe forEntityMapping:mapping]; near the end of the method. – Bawbee

I think I have a bug that's caused by incorrect order of mapping, but I can't seem to drag them around as described in Xcode 5 - is there a trick to it? – Campman

@Luiseluiza You can definitely create relationships in createDestinationInstancesForSourceInstance and have it migrate successfully even though the docs here developer.apple.com/library/ios/documentation/Cocoa/Conceptual/… suggest you implement createRelationshipsForDestinationInstance instead. confusing to say the least – Alpenglow

Answer 2

As I suggested in the comments on the question, you may not want to change your data model, but rather create a bridge between your model and the library that doesn't understand many-to-many relations.

The join table you want to create, is actually already there, you just need another way to present your data to this library.

Whether this could work, depends on how this library looks at your model. There are various ways for it to query the properties of your entities, or it could be that you are the one specifying which properties/relations are to be copied.

It's hard to give a real answer, without any details on all of this, but the general idea is that:

You have some managed objects with headers looking like:

// Recipe.h

@interface Recipe : NSManagedObject
@property (nonatomic,retain) NSSet *ingredients;
@end

and now you add to this object some extra methods, using a category:

// Recipe+fakejoin.h

@interface Recipe (fakejoin)
-(NSSet*)recipeIngredients;
@end

and an implementation in Recipe+fakejoin.m of this method which returns an NSSet with RecipeIngredients objects.

But as I said, it's an open question if this library allows you to play around like this without breaking stuff. If all this sounds new to you, better find another solution...

Schober

Thanks mvds, but I've been talking with the Simperium folks and it doesn't sound like this solution would solve the issue. I appreciate the effort in your answer, though! Simperium requires that there be actual core data representations for the data. – Tigrinya

But what does an "actual core data representation" look like? You can fake almost anything in obj-c. – Schober

@Schober An "actual core data representation" here is probably the entity layout as defined in the CoreData managed object model. And you can't "fake" that by adding some properties to the generated NSManagedObject subclasses. – Spector