small medium large xlarge

Back to: All Forums  Core Data
13 Aug 2009, 17:20
Martin Hewitson (2 posts)

This is not so much a question, as an observation.

Up to this point (chapter 5.4) in the book, I was able to understand and even implement the migration as it was described. However, the learning curve seemed to change abruptly here. The first main problem was that the model for V3 was not at all described. All we got was am image to work from. Then the chapter continues to describe the NSEntityMigrationPolicy class, but at no point are we asked/instructed to implement these subclasses in our project, nor was it made clear how these classes would be used in the mapping model. In fact, there was no mention of how to make a mapping model from V2 to V3. Then comes the real magic: the progressive migration. While the message progressivelyMigrateURL:… was well explained and the code easy(ish) to follow, there was no discussion about where to send this message. So in the end I had to resort to downloading the code example, then all became clear. Up to this point I had found the book fantastic, leading me in to the magical world of core data which had, up to know, appeared very daunting. However, at this point in the book, I felt a little abandoned. Oh well, hopefully I’m back on track now.

06 Nov 2009, 07:19
Martin B (1 post)

I fully agree to this. The migration Chapter was pretty tough to follow for a newcomer to CoreData migration. Without the code it would have been impossible. The mapping model configuration should be explained in detail to be more helpful.

06 Nov 2009, 20:47
Marcus S. Zarra (284 posts)

Thank you for this observation. I will certainly review this chapter for cleaning up in a future revision.

31 Dec 2009, 18:21
Ronald Bell (12 posts)

I’ve downloaded the code, and I’m very curious to know where precisely the @progressivelyMigrateURL:@ method actually is?

Looking at the book, it seems it should be in the @AppDelegate.m@ file. There is no such method, and I downloaded the code again today to see if there’s a more up-to-date version. I’ve done a batch find across the project, and I still can’t find it.

Also, if I do this:

  • delete the underlying datastores in the Application Support>GrokkingRecipes folder

  • run the v1 program to make a new version 1 database

  • run the v3 program…

  • Then I get the “Unable to load the recipes database.” And the error beneath says “Persistent store migration failed, missing mapping model.” There’s NO progressive migration going on, so far as I can see in the downloaded code.

31 Dec 2009, 19:48
Ronald Bell (12 posts)


I have the PDF of the book. So if I click the in-text link “Download ProgressiveMigration/AppDelegate.m”, it sends me to a web page with code that does indeed contain that method.

Furthermore, if I copy that entire file and paste it into the version 3 of AppDelegate.m, the program now migrates v1 to v3.

Now, if I do a batch-find on “progressivelyMigrateURL”, XCode does find it. So it wasn’t there before in the downloaded batch of code. Consider that, for a moment. The code you get if you click on the code link on the web site isn’t the same as the code you get if you click on the “download” link for the PDF. And it’s the code you download as a batch from the website that is incomplete.

Also, as hinted by the OP but not made explicit: neither version of the book points out the changes to the persistentStoreCoordinator method that you have to write in order for your progressivelyMigrateURL: method even to be called. Does no one actually work through the examples themselves prior to publication? You know, there’s a very low percent of people who buy programming books that actually finish them. This kind of thing doesn’t help.

Here is the undocumented version 3 persistentStoreCoordinator, for those who actually made it into C5 and are struggling:

- (NSPersistentStoreCoordinator*)persistentStoreCoordinator;
	if (persistentStoreCoordinator) return persistentStoreCoordinator;
	NSFileManager *fileManager = [NSFileManager defaultManager];
	NSString *applicationSupportFolder = [self applicationSupportFolder];
	if ( ![fileManager fileExistsAtPath:applicationSupportFolder
							isDirectory:NULL] ) {
		[fileManager createDirectoryAtPath:applicationSupportFolder
	NSURL *url = [NSURL fileURLWithPath:[applicationSupportFolder 
	NSManagedObjectModel *mom = [self managedObjectModel];
	persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc]
	NSError *error = nil;
	if (![self progressivelyMigrateURL:url
								 error:&error]) {
		[[NSApplication sharedApplication] presentError:error];
		return nil;
	if (![persistentStoreCoordinator addPersistentStoreWithType:NSXMLStoreType
														  error:&error]) {
		[[NSApplication sharedApplication] presentError:error];
		return nil;
	return persistentStoreCoordinator;
31 Dec 2009, 20:23
Marcus S. Zarra (284 posts)

The code that is in the book is not pasted into the text but is actually fed directly during generation from the projects; the project you just downloaded and had working properly. So yes, the code that is in the book is tested before publication. As for the download links I will need to review that as everything should link up correctly but I will bring this to the attention of PragProg.

31 Dec 2009, 20:29
Marcus S. Zarra (284 posts)

I just downloaded the code from the website link and it contains the method @-progressivelyMigrateURL: ofType: toModel: error:@ as expected. Perhaps you downloaded the code early on or at looking at a different version of the project?

31 Dec 2009, 21:45
Ronald Bell (12 posts)

No, the problem is much more straightforward. While discussing the v3 version of GrokkingRecipes, you transitioned to a different project without calling attention to that fact, and I wasn’t alert enough to catch it.

When I opened the code folder, I saw three versions of GrokkingRecipes: v1, v2, and v3. I foolishly allowed my eye to be drawn to the v3 project and neglected to look hard enough elsewhere. That transfers only part of the frustration I’m feeling to myself, though. You don’t have to hold the reader’s hand, but making major code changes then neglectin to mention them in the book is deadly to a person trying to go through the examples. Leaving out the changes to the @persistentStoreCoordinator@ method is the most painful one so far, but not the only one. The reader should not have to dig through your code to figure out why his program is failing. He’s likely enough to have introduced a bug of his own creation without having to look for undocumented shenanigans going on behind the scenes as well.


You must be logged in to comment