On Jun 18, 2013, at 05:26 PM, Dave Fernandes <dave.fernan...@utoronto.ca> wrote:
> Looks pretty standard, but I would try commenting out the call to > setMetadataForStoreAtURL: I'll try this and report back. > Besides that, I don't know what to suggest. I know, it's a peculiar case. I've performed light migration many, many times, and this is the first time it has taken me more than a couple of minutes to resolve. Thanks, Martin > > On 2013-06-18, at 11:14 AM, Martin Hewitson <martin.hewit...@aei.mpg.de> > wrote: > >> The code is below. Anything look suspicious there? >> >> Thanks, >> >> Martin >> >> - (BOOL)configurePersistentStoreCoordinatorForURL:(NSURL*)url >> ofType:(NSString*)fileType >> modelConfiguration:(NSString*)configuration >> storeOptions:(NSDictionary*)storeOptions >> error:(NSError**)error >> { >> NSMutableDictionary *options = nil; >> if (storeOptions != nil) { >> options = [storeOptions mutableCopy]; >> } else { >> options = [[NSMutableDictionary alloc] init]; >> } >> >> options[NSMigratePersistentStoresAutomaticallyOption] = @YES; >> options[NSInferMappingModelAutomaticallyOption] = @YES; >> BOOL result = [super configurePersistentStoreCoordinatorForURL:url >> ofType:fileType >> modelConfiguration:configuration >> storeOptions:options >> error:error]; >> options = nil; >> >> if (result) { >> NSPersistentStoreCoordinator *psc = [[self managedObjectContext] >> persistentStoreCoordinator]; >> NSPersistentStore *pStore = [psc persistentStoreForURL:url]; >> id existingMetadata = [psc metadataForPersistentStore:pStore][(NSString >> *)kMDItemKeywords]; >> if (existingMetadata == nil) { >> result = [self setMetadataForStoreAtURL:url]; >> } >> } >> >> return result; >> } >> >> >> >> >> On Jun 18, 2013, at 05:04 PM, Dave Fernandes <dave.fernan...@utoronto.ca> >> wrote: >> >>> 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]. >>>>>> >> >> >> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ 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