In the Core Data Programming Guide > Managed Object Models, "A persistent store coordinator can only have one managed object model, so by default each store associated with a given coordinator must contain the same entities. To work around this restriction ... You typically use configurations ..."
Well, I have a document-based Core Data app and would like to store some logging stuff in an sqlite store in ~/Application Support/MyApp/. The entities modelling the logging stuff are all different than the entities in the document's model. So, I believe I'm in the situation described above. Yes, it *seems like it would be inefficient* to add the logging entities to the existing managed object model. To me, the natural solution would be to create a whole new persistence stack based on another managed object model for my logging stuff. Yet the documentation seems to suggest that I instead pack the new entities into the existing managed object model and then segregate them using a "configuration". Am I reading this correctly? What is so bad about multiple managed object models that we invented "configurations" just to avoid them? But wait, a paradox ... There are five "Initializing" methods in NSManagedObjectModel. Four of them involve "merging" models, and indeed one of these is used in the Xcode Core Data non-document-based template project. Apparently it is common to "merge" managed object models. When is this done? My app's bundle contains three managed object models, but they are for versioning; a current version and two older versions. When I create an in-memory store for temporary manipulation, following that Xcode template code I create a managed object model using [NSManagedObjectModel mergedModelFromBundles:nil]. Eeek. Is this merging my old and current model versions? If so, why doesn't that give me "Can't merge models with same entities" errors? Would it be better to initialize this managed object model using only the current version, with -[NSManagedObjectModel initWithContentsOfURL:]? To do that I'd need to pass a file URL to the current model resource. Hard-coding that would be fragile. Core Data seems to have no problem identifying the current model resource, but an API for this seems conspicuously absent. How can I get the file URL of the *current* model resource? Thank you for reading all this! Jerry Krinock _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
