What does your configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error: do?
On 2013-06-18, at 5:09 AM, Martin Hewitson <martin.hewit...@aei.mpg.de> wrote: > Another question on this problem: does anyone know if > NSStoreModelVersionIdentifiers is used in looking for a source model to infer > a mapping model from? > > To recap: > > 1) Loading an existing document with the version 11 model works > 2) Adding a new version (12) with a single new boolean property on one entity > triggers an automatic migration but the source model is not found > 3) During the failure, all hashes match between the XML store and the current > model version except for the one entity I modified (so the migration is > correctly triggered) > 4) I've confirmed the source model can be loaded in principle by using > -metadataForPersistentStoreOfType: and > -mergedModelFromBundles:forStoreMetadata: > 5) With the new version 12 model I can successfully create new documents then > save and load them. > 6) Overriding -managedObjectModel in my NSPersistentDocument to ensure the > correct momd is loaded doesn't fix the problem. > > I'm at a bit of a loss what to try next.... > > Martin > > > On Jun 18, 2013, at 08:38 AM, Dave Fernandes <dave.fernan...@utoronto.ca> > wrote: > >> cc'ing the list this time… >> >> On 2013-06-18, at 2:26 AM, Martin Hewitson <martin.hewit...@aei.mpg.de> >> wrote: >> >>> >>> On Jun 18, 2013, at 08:08 AM, Jerry Krinock <je...@ieee.org> wrote: >>> >>>> >>>> On 2013 Jun 17, at 21:13, Martin Hewitson <martin.hewit...@aei.mpg.de> >>>> wrote: >>>> >>>>> I did try making a mapping model (this is something I've done in the past >>>>> in other apps) but I got the same error message. >>>> >>>> Oh, well. >>>> >>>>> Is the idea that the auto-migration magic will pick up the mapping model >>>>> and use it, if it finds it? >>>> >>>> Yes. I think the only three things you need do are to specify the current >>>> version, and add .xcdatamodel and .xcmappingmodel files to your app >>>> target. Xcode compiles the .xcdatamodel files into .mom files that all >>>> get put into a .momd folder which also contains a VersionInfo.plist that >>>> specifies the current version and the hashes for the entities in each >>>> version; also it compiles each .xcmappingmodel files into a .cdm file. >>>> Finally, the .momd folder and all the .cdm files get packaged into your >>>> product's Resources. Given those pieces, it's a pretty easy >>>> reverse-engineering exercise to figure out what the auto-migration magic >>>> must be doing. >>> >>> According to your description, my app bundle's in good shape. I tried >>> making a mapping model and the cdm file shows up in Resources, as expected. >>> The momd folder contains all the expected mom and one omo file. >>> >>>> >>>> Lately, Xcode has also been adding a .omo file, just one, named for the >>>> current version, to the .momd. On Stack Overflow, 'Bobson' guessed that >>>> this was "the same data [as the .mom file], organized differently". >>>> Probably not a bad guess. Maybe optimized for faster access by Mountain >>>> Lion or something. >>> >>> Yes, I just noticed this ono file in the app bundle. I was wondering what >>> that was... >>> >>> <snip> >>> >>>>> Then I go to open an existing document and I get the dreaded "migration >>>>> failed, missing source managed object model" error. >>>> >>>> >>>> After writing this message, you know I think it's more likely that you >>>> screwed up and did this… >>>> >>>> • Change the data model a little. >>>> • Create a document, "E". >>>> • Get interrupted by a fire drill. >>>> • Change the data model a little more. >>>> • Build. >>>> >>>> In this case, indeed *no* version of your app will ever be able to open >>>> that document "E". If this is your "existing" document, the "migration >>>> failed, missing source managed object model" error is expected. >>> >>> I don't think this is the case since I can still drop back to version 11 >>> and open the 'existing' document. I just made a test app and managed to >>> perform a lightweight migration much like the one I'm trying here, so I >>> guess I'm doing something wrong. I'll try to absorb your other detailed >>> comments and see if I can get some more debug output to figure out what's >>> going on. >>> >>> I just had another thought.... I have another core data model in the app. I >>> wonder if the NSPersistentDocument infrastructure is picking up the wrong >>> model? As I'm looking through the project, I realise I don't know how the >>> document knows which core data model to use.... OK, back to the >>> documentation on NSPersistentDocument. >>> >> >> By default it will merge all models in the main bundle. So if the other >> model changed, you would also have a problem. If you want to specify only >> one model for the document, you should override [NSPersistentDocument >> managedObjectModel]. >> >> >>> Thanks again, >>> >>> Martin >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca >>> >>> This email sent to dave.fernan...@utoronto.ca >> > > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
