04 Jan 2012, 01:36
Generic-user-small

Mark C (6 posts)

As I work through example one… and compile and then make any small changes, and compile again, I get this error:

“The managed object model version used to open the persistent store is incompatible with the one that was used to create the persistent store.”

This is really maddening… as so far, I can’t get example one to work right… and this is after a year of owning the book. I didn’t understand somethings, so I spent time on other books, and was able to work through their examples… and overcome my own misunderstandings… and now I’m getting back to this book, but I’m getting really frustrated…

To me the book needs a rewrite… It needs to be more explicit and less ambiguous, and I’d rather see a stepwise, delineated, approach which the user can follow, and the run/compile… and if it doesn’t work, the reader would go back, and catch his own mistakes… until it compiles. Then, of course, text explaining what is going on, could and should follow afterwards… for each example or bit…

Like the text covering the NSArrayController in the xib for RecipeIngredient is too vague, or not explicit enough when it talks about bindings… I think I finally “got” that… but so far, I’ve got it so that Recipes can be added, and RecipeIngredients can be added.. but RecipeIngredients so far, can’t be saved… though Recipes can…

If the book had a more stepwise approach, and allowed me to make example one in smaller pieces (which is going to require informing the audience, what do you do about that error code)… I would be half way through the book at this point, and would at least have a better overview of CoreData…

I’ve highlighted all the code that needs to be coded, so that when I get in front of the computer, I’m not “reading” text that doesn’t need to be coded… Even then, I’m getting stuck over and over and over again. Someone with a couple years programming experience might see my complaints as insignificant… but even they could finish the book faster if it were a more stepwise approach. Anyway… I don’t see anything in the Application Support directory that looks like example one… so I can’t delete what I can’t find… That’s the problem isn’t it? The model or persistent store has changed and needs to be deleted so it can be created fresh?

04 Jan 2012, 20:52
Avatarsmall_pragsmall

Marcus S. Zarra (245 posts)

Mark,

I can certainly understand your concerns. However this is not an introductory book. It specifically assumes that you have knowledge and understanding of Cocoa and Objective-C. This is done to keep the book focused on its target. If this text included a discussion on bindings and other out of scope items it would be far more voluminous.

As for the error you started your post on, that error is telling you that your existing store file (database, xml file, binary file) is using an older version of the model. If you are not yet to the point of the versioning chapter then I would suggest deleting the app between runs and clearing its Application Support folder. This will give you a clean run on the application each time.

24 Jan 2012, 05:32
Generic-user-small

Mark C (6 posts)

Um, thanks for the response. I did look in the Application Support folder, and I don’t see anything that resembles the application, or it’s model. I’d love to be able to find it, whatever is stored there, and delete it. That’s what really aggravated me: I was/am just trying to add a little bit of the model and compile, then add a little more of the model, and compile again, and that error comes up… To me, migration would be more for when you want to retain data saved under an former model and move the data into a newer version of the model. I have no need to save or retain any data at this stage. I just want to be able to build the model in pieces, as I go along. So deleting the entire app and starting over from the beginning would run against the grain of my intent and desire.

If you like, I can send you sentences that left me puzzled, which, to me at least, would have been quicker to understand if they had been phrased differently. I’m not saying it’s a bad book, I just get aggravated, because I want to learn this now, and not later.

24 Jan 2012, 21:31
Avatarsmall_pragsmall

Marcus S. Zarra (245 posts)

I would suggest that you print out the path that Core Data is using when it creates the NSPersistentStore. That will tell you what file you need to delete.

Whenever you are developing like you are, you need to delete the file that is being saved or turn saving off. Otherwise the file will get created and you are going to run into issues when you change the model.

One suggestion, that is a little more advanced: Have Core Data check to see if the file on disk is compatible and if it is not then delete it and build a new one. If you are interested I can post that code (although I prefer to post things like that over at stackoverflow.com so that it is more visible to others).

26 Jan 2012, 03:39
Generic-user-small

Mark C (6 posts)

Could you maybe post how to “print out the path that Core Data is using when it creates the NSPersistentStore” ?

Maybe you could post it on stack overflow and put a link to it here?

I google it and go around in circles. This is the stumbling block for me that is leaving me in the wilderness. I think I can make it to to the end of the book if I can get past this.

I tried this:

- (IBAction)printStore:sender
{
    NSPersistentStore *store = [[__persistentStoreCoordinator persistentStores] objectAtIndex:0];
    NSLog(@"%@", store);
}

But that gave me this:

2012-01-25 19:21:25.887 CoredataText002[10609:903] <NSXMLObjectStore: 0x130310>

OR, oh maybe this works:

- (IBAction)printStore:sender
{
    NSPersistentStore *store = [[__persistentStoreCoordinator persistentStores] objectAtIndex:0];
    NSLog(@"%@", store);

    id path = store.URL.path;
    NSLog(@"%@", path);
}

Oh, I guess that must work… it shows a file named *.storedata

And now, oddly, I can see some other folders of previous Core Data projects I was trying to make with your book. Guess I was so aggravated by that error message that I just could NOT SEE the folders containing these *.storedata files (which are in ~/Library), but.. based on what I found online, and maybe elsewhere, I was looking for these in ~/Library/Application Support/

So it wasn’t my visual focus, it was my folder focus. Gee, now I can build a little project in pieces, before even considering Migration :)

26 Jan 2012, 03:43
Generic-user-small

Mark C (6 posts)

CORRECTION, I meant to write the “OR, oh maybe this works:” like this:

  • (IBAction)printStore:sender { NSPersistentStore *store = [[__persistentStoreCoordinator persistentStores] objectAtIndex:0]; NSLog(@”%@”, store);

    id path = store.URL.path; NSLog(@”%@”, path);

}

which outputs a Core Data store path to the console in Xcode

26 Jan 2012, 03:46
Generic-user-small

Mark C (6 posts)

One more try (as the layout/format in the post is wrong for some reason):

  • (IBAction)printStore:sender { NSPersistentStore *store = [[__persistentStoreCoordinator persistentStores] objectAtIndex:0]; NSLog(@”%@”, store);

    id path = store.URL.path; NSLog(@”%@”, path);

}

which outputs a Core Data store path to the console in Xcode

26 Jan 2012, 03:48
Generic-user-small

Mark C (6 posts)

Well, I give up (not on the code [it works], but on the format of the post). Can you fix the formatting. Thanks for suffering my impatience.

27 Jan 2012, 08:07
Avatarsmall_pragsmall

Marcus S. Zarra (245 posts)

Print it when you create it.

In the method that constructs the NSPersistentStoreCoordinator you have the file path that it is going to be saving to. Put an NSLog right there and you will know where the file is.

BTW, I cannot edit your posts :)

  You must be logged in to comment