Yes, alas, alas I have tried all of that and checked all settings, to no avail.
If I select the old model version, everything works fine (at least old documents can be opened). Thanks, Martin On 18 Jun 2013, at 19:00, [email protected] wrote: > > Are you 100% certain you set the "Versioned Core Data Model" "current" > setting to the latest model in the inspector pane on the right side of Xcode. > > Have you tried doing a clean and rebuilding? I think I once had an issue > where it didn't seem to start using the new model until I did a clean build > (or in my case for iOS, also deleted the app from the simulator and rebuilt > it so it installed the app fresh in the simulator). > > HTH, > Dave > > > On Jun 18, 2013, at 11:37 AM, Martin Hewitson <[email protected]> > wrote: > >> >> On Jun 18, 2013, at 05:26 PM, Dave Fernandes <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> wrote: >>>> >>>>> What does your >>>>> configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error: >>>>> do? >>>>> >>>>> On 2013-06-18, at 5:09 AM, Martin Hewitson <[email protected]> >>>>> 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 >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> cc'ing the list this time… >>>>>>> >>>>>>> On 2013-06-18, at 2:26 AM, Martin Hewitson <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Jun 18, 2013, at 08:08 AM, Jerry Krinock <[email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On 2013 Jun 17, at 21:13, Martin Hewitson >>>>>>>>> <[email protected]> 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]. >>>>>>>> _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
