For the record, I thought I would post the solution to this thorny problem.
During the various checks as part of the DTS activity, I found the bug. I have
two core data models in the app, but I had not implemented
-managedObjectModel
in my NSPersistentDocument subclass and as such the document XML stores
contained entities from both models. This was then causing the lightweight
migration to fail because the model for the document didn't match all the
entities in the store file.
To 'fix' users' documents, I used NSManagedObjectModel's
-isConfiguration:compatibleWithStoreMetadata: to test the store file against
the model, then if that failed I repaired the XML store by removing the
unnecessary entity descriptions, then let the lightweight migration carry on.
Seems to work just fine.
This should have been easy to see, but for some reason it took me ages to see
that there were two extra entities in the XML store. In my defence, the DTS guy
didn't spot it either :)
Cheers,
Martin
On Jun 18, 2013, at 09:18 PM, Martin Hewitson <martin.hewit...@aei.mpg.de>
wrote:
> OK, I tried commenting out the setMetadataForStoreAtURL: part, but still it
> fails.
>
> Maybe I'm going to have to use one of my precious DTS tickets for this.
>
> Martin
>
> On Jun 18, 2013, at 08:32 PM, Martin Hewitson <martin.hewit...@aei.mpg.de>
> wrote:
>
>> 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, davel...@mac.com 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 <martin.hewit...@aei.mpg.de>
>>> wrote:
>>>
>>>>
>>>> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
