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
