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]
