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.
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. 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. 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? 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/archive%40mail-archive.com This email sent to [email protected]
