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
