Re: Removing or ignoring relationship from a parent class in a subclass
Re: Removing or ignoring relationship from a parent class in a subclass
- Subject: Re: Removing or ignoring relationship from a parent class in a subclass
- From: Paul Hoadley <email@hidden>
- Date: Wed, 05 Oct 2011 13:21:41 +1030
Hi Ramsey,
On 05/10/2011, at 12:58 PM, Ramsey Gurley wrote:
> On Oct 4, 2011, at 5:17 PM, Paul Hoadley wrote:
>
>> We have a framework that handles, among other things, authentication of users for applications. It has an entity called Person which is generally subclassed by applications to add attributes/relationships relevant to the app. For example, FooApp might have an entity FooPerson which inherits from Person, and adds the FooPerson.foos relationship to some Foo entity. It works quite well.
>
> Out of curiosity, what kind of inheritance? Single table, horizontal, or vertical?
Horizontal.
>> We've added some new functionality to the framework. Specifically, usage "plans". Among other things, Person now has an optional 'plan' relationship to a Plan entity. Here's the rub: some apps will want to use this feature, and others won't. What I would like to avoid is making _any_ changes to the applications that _don't_ want to use this.
>
> Then don't modify Person.
>
>> If I merge this feature back into the trunk, legacy apps are going to break immediately, because FooPerson isn't going to have a 'plan' attribute that it should be inheriting from Person. At runtime there's going to be a missing table column as soon as I fetch a FooPerson, and at development time, every time I touch the model or generate the EO classes, the unwanted 'plan' attribute is going to be added.
>
> Which is why you don't want to modify Person (^_^)
I couldn't see a way around it until..
> Two strategies come to mind:
>
> 1) Add a new Person subclass that has a plan relationship and extend that for the subclasses that need to have a plan.
>
> 2) If you don't need a real relationship on the person class, add a detached table with a relationship to person and plan. Make a unique index on the person column. That will give you either 0 or 1 plans per person without needing to modify the person entity at all.
Thanks for those ideas. 1 sounds the easier of the two—I'll start there.
--
Paul.
http://logicsquad.net/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden