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 protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
