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: Ramsey Gurley <email@hidden>
- Date: Tue, 04 Oct 2011 19:28:07 -0700
On Oct 4, 2011, at 5:17 PM, Paul Hoadley wrote:
> Hello,
>
> 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?
> 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 know what I am asking is, uh, insane: how can I have a subclass of an entity that removes one of that entity's relationships? Obviously I can't. But is there a solution to this kind of problem that doesn't involve (a) adding the superfluous baggage to legacy apps that don't need the feature, or (b) forking the framework into versions with and without the feature?
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.
Ramsey
> Obviously I could modify the model at runtime, perhaps based on a property set by the apps that want the feature, but I'm still going to be stuck with WOLips complaining and changing things for me at development-time, aren't I?
>
>
> --
> 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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