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 protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/ramseygurley%40gmail.com > > This email sent to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
