Re: core data lightweight migration woes
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)
Re: core data lightweight migration woes
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. 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. Getting back to your issue, if you are 100% sure that Xcode is building and packaging all of those files, and are at a dead end in troubleshooting the dreaded missing source managed object model, you're welcome to look under the hood. Here is how I think it works. The signature of a managed object model is a dictionary whose keys are the model's entity names and whose values some kind of hash of the properties of each entity. These are given in that VersionInfo.plist file. A similar dictionary is in any Core Data document file (at, sqlite, that's all I've ever looked into), as the first and only row of the Z_METADATA table, in the Z_PLIST column. It's serialized into a plist. You can write it out to a file using the sqlite3 command-line tool included with OS X or else an app like SQLiteManager. I'd say that if the Core Data runtime can't find an equal dictionary in your app's VersionInfo.plist, you get the booby prize, missing source managed object model. So you can check this yourself manually. Or, use the methods that Core Data does. They're all public… -[[NSPersistentStoreCoordinator metadataForPersistentStoreOfType:nilURL:urlerror:] -[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:] etc. To find a mapping model, -[NSMappingModel mappingModelFromBundles:sourceModel:destinationModel:destinModel] But, come to think of it, that would happen later. Core Data is not making it that far. Stepping back, 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. ___ 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
Re: core data lightweight migration woes
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. Thanks again, Martin ___ 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
Re: core data lightweight migration woes
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]. Thanks again, Martin ___ 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/dave.fernandes%40utoronto.ca This email sent to dave.fernan...@utoronto.ca ___ 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
Re: core data lightweight migration woes
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]. Yes, thanks. I got that from the documents, but doing an override and explicitly pointing to the model doesn't help. I have then gone on to check the entity hashes in the XML store on disk against the hashes in the model loaded for that XML store using this snippet: NSError *metaerror = nil; NSDictionary *storeMeta = [NSPersistentStoreCoordinator metadataForPersistentStoreOfType:nil URL:url error:metaerror]; NSLog(@Metadata at URL %@, storeMeta); NSManagedObjectModel *oldManagedObjectModel = [NSManagedObjectModel mergedModelFromBundles:@[[NSBundle mainBundle]] forStoreMetadata:storeMeta]; NSLog(@Old managed object model %@, [oldManagedObjectModel entityVersionHashesByName]); and the hashes all match. So I don't know why the migration says it's can't locate the source model since I can locate it myself. More digging... Cheers, Martin ___ 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
Re: core data lightweight migration woes
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]. Thanks again, Martin ___ 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/dave.fernandes%40utoronto.ca This email sent to dave.fernan...@utoronto.ca ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please
Re: core data lightweight migration woes
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]. Thanks again, Martin ___ 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:
Re: core data lightweight migration woes
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.
Re: core data lightweight migration woes
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],
Re: core data lightweight migration woes
Looks pretty standard, but I would try commenting out the call to
setMetadataForStoreAtURL:
Besides that, I don't know what to suggest.
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
Re: core data lightweight migration woes
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,
Re: core data lightweight migration woes
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
Re: core data lightweight migration woes
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
Re: core data lightweight migration woes
I don't see anything wrong in what you've done Martin. And I am ashamed to admit that I have a few more version numbers than you in one of my apps. I think the only thing I do differently is that I always create a mapping model, whether it needs it or not. Lightweight migration has always seemed too opaque for my taste. Creating a do-nothing mapping model just takes a few minutes, certainly less time than you spent writing and editing your post :) If you've not fixed this yet, you should give it a try. ___ 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
Re: core data lightweight migration woes
Hi Jerry, 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. Is the idea that the auto-migration magic will pick up the mapping model and use it, if it finds it? Many thanks, Martin On Jun 17, 2013, at 10:42 PM, Jerry Krinock je...@ieee.org wrote: I don't see anything wrong in what you've done Martin. And I am ashamed to admit that I have a few more version numbers than you in one of my apps. I think the only thing I do differently is that I always create a mapping model, whether it needs it or not. Lightweight migration has always seemed too opaque for my taste. Creating a do-nothing mapping model just takes a few minutes, certainly less time than you spent writing and editing your post :) If you've not fixed this yet, you should give it a try. ___ 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/martin.hewitson%40aei.mpg.de This email sent to martin.hewit...@aei.mpg.de ___ 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
Re: Core Data Lightweight Migration Woes
On Sat, Aug 21, 2010 at 5:22 PM, Brad Gibbs bradgi...@mac.com wrote: Well, that's the way I started doing things, but, on pages 130-131 of the book More iPhone 3 Development (written by Dave Mark Jeff LaMarche -- your co-authors for Learn Cocoa on the Mac) make a point of saying that the new version is the unnumbered version. Well! Either I stand corrected, or I'll have to correct my compadres on that front... I wish I could submit a simplified version to Apple, but, since I have no idea what's actually causing the problem and I can't seem to replicate it in the little test apps I've been making, I don't know how I'd do that. I do live about 45 minutes from Cupertino. Maybe it's time to pester Chris Hanson at the next NSCoder Night... If you're just seeing this intermittently, then yeah, this is a mystery that may be hard to report a bug against. What you *could* do, though, is submit a bug report asking them to improve the logging that they're already doing when the weirdness happens; Hopefully that would make it easier to spot the actual problem. Of course, even doing that wouldn't help you much now, unless they turn it around really quick and squeeze it into the next 10.6 release :/ -- // jack // http://nuthole.com // http://learncocoa.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Lightweight Migration Woes
On Aug 22, 2010, at 04:29, Jack Nutting wrote: On Sat, Aug 21, 2010 at 5:22 PM, Brad Gibbs bradgi...@mac.com wrote: Well, that's the way I started doing things, but, on pages 130-131 of the book More iPhone 3 Development (written by Dave Mark Jeff LaMarche -- your co-authors for Learn Cocoa on the Mac) make a point of saying that the new version is the unnumbered version. Well! Either I stand corrected, or I'll have to correct my compadres on that front... Well, you're both wrong, really: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmVersioning.html There's no actual version number for the compiled model, only a version string, and Core Data does nothing with it, other than to identify which model in a '.momd' package is the current model for the application. Also, there's no implied order amongst models. So, after duplicating a model in Xcode, you should be able to choose either the original or the copy as the current model. I wish I could submit a simplified version to Apple, but, since I have no idea what's actually causing the problem and I can't seem to replicate it in the little test apps I've been making, I don't know how I'd do that. I do live about 45 minutes from Cupertino. Maybe it's time to pester Chris Hanson at the next NSCoder Night... If you're just seeing this intermittently, then yeah, this is a mystery that may be hard to report a bug against. The intermittent nature of the problem deserves some further attention, because there's absolutely nothing in the documentation (AFAICT) or in this thread so far that would explain the outcome being anything other than deterministic. It would be useful to know: 1. Given an already-created store and an already-built application that migrates the store, is the outcome always the same? (I mean, test by re-copying the files before each test run.) 2. If it is the same, what has to change to produce a different result? Re-creating the store? Re-building the application? Re-compiling the model? Changing the model? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Lightweight Migration Woes
On Fri, Aug 20, 2010 at 8:46 PM, Brad Gibbs bradgi...@mac.com wrote: I highlighted the .xcdatamodel and did a Design Data Model Add New Version. That created the Config.xcdatamodeld with an unnumbered version of the datamodel (Config.xcdatamodel) and a numbered copy named Config 2.xcdatamodel. I go into Config.xcdatamodel and add a single string attribute to one entity, Clean and Build Go. I get the missing source model error. I think you're looking at the versioning the wrong way around! The data model with the 2 in its name is the new one, THAT's where you should add new attributes etc. When your app runs, it will find the existing data store which is version 1, both model files (the old one is 1, the new one is 2), and do the conversion for you. I don't have it in front of me, but I think that if you bring up the info window for each of the model files, you'll see that each shows a version number. Core Data will always work to bring lower-versioned data stores up to whatever you've marked as the current version. -- // jack // http://nuthole.com // http://learncocoa.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Lightweight Migration Woes
Well, that's the way I started doing things, but, on pages 130-131 of the book More iPhone 3 Development (written by Dave Mark Jeff LaMarche -- your co-authors for Learn Cocoa on the Mac) make a point of saying that the new version is the unnumbered version. In some ways, I wouldn't think it would matter. When first created, they're exact replicas, and you can change the names of both of these files. What the compiler(?) is looking for are the version hashes for each of the entities. As long as it can find both the version marked current and another version with entity hashes that match those stored in the data file to be migrated, I would think it would be able to decide which is the old version, and which is the new. My classes are organized into folders on my desktop (and in Git). I pulled all four data models out of folders and put them at the top level of the folder hierarchy. This *seems* to have helped. Although I've still gotten the missing source model error since then, it seems to be happening less frequently. The other thing I did was to create a new set of data while the section of code that merges the second data model in with the main data model was commented out. After the model was created, I uncommented that code and made changes to the first model and everything seems ok. It made me realize that I don't know whether the app is having a hard time finding the source model for the first model, or, if it thinks that there should be two versions of the second model. Since there's only a single version of the second model (.mom), it may be getting hung-up there, although that would seem to be more of a bug than user error. I wish I could submit a simplified version to Apple, but, since I have no idea what's actually causing the problem and I can't seem to replicate it in the little test apps I've been making, I don't know how I'd do that. I do live about 45 minutes from Cupertino. Maybe it's time to pester Chris Hanson at the next NSCoder Night... On Aug 21, 2010, at 7:37 AM, Jack Nutting wrote: On Fri, Aug 20, 2010 at 8:46 PM, Brad Gibbs bradgi...@mac.com wrote: I highlighted the .xcdatamodel and did a Design Data Model Add New Version. That created the Config.xcdatamodeld with an unnumbered version of the datamodel (Config.xcdatamodel) and a numbered copy named Config 2.xcdatamodel. I go into Config.xcdatamodel and add a single string attribute to one entity, Clean and Build Go. I get the missing source model error. I think you're looking at the versioning the wrong way around! The data model with the 2 in its name is the new one, THAT's where you should add new attributes etc. When your app runs, it will find the existing data store which is version 1, both model files (the old one is 1, the new one is 2), and do the conversion for you. I don't have it in front of me, but I think that if you bring up the info window for each of the model files, you'll see that each shows a version number. Core Data will always work to bring lower-versioned data stores up to whatever you've marked as the current version. -- // jack // http://nuthole.com // http://learncocoa.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Lightweight Migration Woes
Hi Brad, After much struggle and even writing a nightmare migrator app, I discovered one day that the lightweight migration really does work. In broad brush strokes here's what I did: - Removed all the complicated migration support code that had never worked... - ...except the code that ensured that the options dictionary which is passed to addPersistentStoreWithType included these two options: NSMigratePersistentStoresAutomaticallyOption NSInferMappingModelAutomaticallyOption - Made sure the old and new models were both in the xcdatamodeld package and that the new one was the 'Current' one (litte green dot on the icon). - Removed any stray mopping models, just in case - Cleaned (important, I think) and launched the application - Watched with delight (and woke my family) when it created a new database and archived the old one. But you probably know all that already. Cheers, Steve ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Lightweight Migration Woes
On Fri, Aug 20, 2010 at 8:21 AM, Steve Steinitz stein...@datatactics.com.au wrote: - Removed any stray mopping models, just in case I didn't see your question until you'd already solved it yourself, but I just wanted to highlight this one point; Assumming you're referring here to old .mom files, I'd almost bet money that this is the only thing you needed to do (either manually delete the old file from your target app, or build clean). Like Quincey mentioned, if your app at runtime finds both Model.mom and Model.momd, it will use the former and then either ignore the latter or give you cryptic errors (I forget which). -- // jack // http://nuthole.com // http://learncocoa.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Lightweight Migration Woes
I'm still having some serious issues. I've tried all suggestions from all three responses. One or two of the suggestions worked once or twice, but nothing worked reliably. Is it possible that the dataModel itself is corrupt? I rebuilt it by creating a new data model and copying all of the objects into it. Didn't make a difference. After copying the entities into the new data model and rearranging them, I created the custom classes for each. I've been putting my methods in categories on each of the individual classes so I can quickly delete the custom classes and re-create them after making model changes without having to cut and paste the methods. I ran the app once to confirm that it was working and added some sample data, saved and quit. I highlighted the .xcdatamodel and did a Design Data Model Add New Version. That created the Config.xcdatamodeld with an unnumbered version of the datamodel (Config.xcdatamodel) and a numbered copy named Config 2.xcdatamodel. I go into Config.xcdatamodel and add a single string attribute to one entity, Clean and Build Go. I get the missing source model error. Quincey, you asked about the log for PrototypePath. It's: 2010-08-20 11:44:12.044 IconConfig[86221:a0f] Prototype path is /Users/brad/iconConfigClone/IconConfig/IconConfig/build/Debug/IconConfig.app/Contents/Resources/Config.momd 2010-08-20 11:44:12.046 IconConfig[86221:a0f] Prototype URL is file://localhost/Users/brad/iconConfigClone/IconConfig/IconConfig/build/Debug/IconConfig.app/Contents/Resources/Config.momd/ If I delete the attribute I just added, it compiles and runs. The two versions appear in my target's Compile Sources, but the .xcdatamodeld does not. Could this have something to do with the problems I'm having? Is there some build setting that might be causing this? I don't think there's anything tricky going on with my -managedObjectModel or -persistentStoreCoordinator, but, I'd be glad to post the code. Thanks in advance. This is driving me nuts! Brad On Aug 20, 2010, at 12:28 AM, Jack Nutting wrote: On Fri, Aug 20, 2010 at 8:21 AM, Steve Steinitz stein...@datatactics.com.au wrote: - Removed any stray mopping models, just in case I didn't see your question until you'd already solved it yourself, but I just wanted to highlight this one point; Assumming you're referring here to old .mom files, I'd almost bet money that this is the only thing you needed to do (either manually delete the old file from your target app, or build clean). Like Quincey mentioned, if your app at runtime finds both Model.mom and Model.momd, it will use the former and then either ignore the latter or give you cryptic errors (I forget which). -- // jack // http://nuthole.com // http://learncocoa.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Lightweight Migration Woes
On Aug 20, 2010, at 11:48, Brad Gibbs wrote:
- (NSManagedObjectModel *)managedObjectModel {
Here's what the lightweight migration documentation says:
To perform a lightweight migration, Core Data needs to be able to find the
source and destination managed object models itself at runtime. (Core Data
searches the bundles returned by NSBundle’s allBundles andallFrameworks
methods.)
(http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweight.html)
When I read this yesterday, I didn't pay any attention to the word itself,
but maybe it's important. Taken literally, it would suggest that you can't use
lightweight migration if you're supplying the model yourself, and that Core
Data must be able to find the model by its own bundle search. I don't think
those conditions are met in your project.
A bug report with a simple project is probably your next step, to find out if
this is a documentation bug, or a functional requirement.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Core Data Lightweight Migration Woes
On Aug 19, 2010, at 14:31, Brad Gibbs wrote:
// create object for prototype model
NSString *prototypePath = [[NSBundle mainBundle]
pathForResource:@IconConfig ofType:@mom];
if (prototypePath == nil) {
prototypePath = [[NSBundle mainBundle]
pathForResource:@IconConfig ofType:@momd];
}
NSLog(@Prototype path is %@, prototypePath);
What is shown as the prototype path?
Note that there *is* (presumably) a resource called IconConfig.mom -- inside
the IconConfig.momd directory -- which contains your current model. If your
code is finding that, then it won't look for IconConfig.momd, and so the
returned model will look (presumably) to Core Data as if there's only one
version.
Have you tried reversing this test, so that it finds the momd resource first,
and only looks for the mom resource if there's no momd?
Also, have you tried examining the results of NSMappingModel’s
inferredMappingModelForSourceModel:destinationModel:error: method?
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
