Re: CoreData, inheritance and plug-ins
Re: CoreData, inheritance and plug-ins
- Subject: Re: CoreData, inheritance and plug-ins
- From: Miguel Sanchez <email@hidden>
- Date: Thu, 10 Nov 2005 15:55:17 -0800
two things:
+ the original post might have been asking if the
modelByMergingModels would automatically do the parent-child hookup
of the entities. If this was the question, the answer is no. You
won't be able to declare the parent of a class within the modeling
tool if that parent isn't in the same model you're editing. You'll
have to figure out a way of encoding this parent dependency, either
by creating a dummy parent class that get swiped for the real one, or
putting the name of the parent in the user info of the entity. In any
case, you'll need to have code that tweaks your child model by
- calling modelByMergingModels
- and then setting the parent-child relationships in the resulting
model
+ it's true that "The shape of the store depends on the entities/
attributes/relationships in the data model", but remember that a
persistent store coordinator can split entities into separate stores,
or even by configurations. The original post said nothing about the
"expanded data" all being in the same store.
these are high level answers since you really don't explain how the
functionality of your app will be expanded.
- Miguel
On Nov 10, 2005, at 2:29 PM, Jim Correia wrote:
On Nov 10, 2005, at 3:47 PM, Bill Dozier wrote:
I would like for my CoreData application to be extensible via plug-
ins. One of the things the plug-ins would do is to extend by
inheritance the abstract entities in my data model. I'm planning
to call:
+ (NSManagedObjectModel *)modelByMergingModels:(NSArray *)models
after loading each plug-in. Is this the preferred method?
I think you'll find that this isn't going to work. The shape of the
store depends on the entities/attributes/relationships in the data
model. If plug-ins are allowed to define entities (otherwise why
else would you be doing this), consider the following scenario:
Application + Plug-in 1 + Plug-in 2:
We'll call this aggregate model version 1. User creates a document
1 and saves.
User buys/downloads Plug-in 3, installs it.
We'll call this aggregate model version 2. User creates document 2
and saves it.
Document 1 is now in an incompatible format, and one which you
can't readily migrate yourself because you really don't have
intimate knowledge of all the parts of aggregate model version 1
(or 2.)
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden