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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
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
