Re: Multiple EO classes inheriting from one abstract superclass?
Re: Multiple EO classes inheriting from one abstract superclass?
- Subject: Re: Multiple EO classes inheriting from one abstract superclass?
- From: Chuck Hill <email@hidden>
- Date: Thu, 6 Aug 2009 14:45:47 -0700
On Aug 6, 2009, at 2:29 PM, David Avendasora wrote:
On Aug 6, 2009, at 4:10 PM, Andrew R. Kinnie wrote:
Greetings:
I have four tables in a database, which are materialized views from
an oracle db. All four share 12 columns, which are basically
numerical values.
I have 4 components which display repetitions based on these four
tables. I have these inheriting from one abstract superclass
containing the calculations on the 12 values.
It seemed to me logical, and very object oriented to have these 4
eo tables inherit from 1 abstract superclass containing the 12
shared attributes.
I modeled this and checked the "Abstract" checkbox in Entity
Modeler. I did not select a source table as this class is supposed
to be abstract.
The problem is, Entity Modeler wants me to have a primary key for
the abstract eo superclass, but the 4 subclasses have different
primary keys representing different foreign keys from their source
tables. Some of these keys are multiple foreign keys from multiple
source tables (i.e. the eo is essentially a join)
If I let Entity Modeler set a primary key of "id" and delete the
inherited "id" primary keys from the subclasses (leaving the
previously existing primary keys, just pointing the subclass eos to
the new superclass), I get an SQL error because the tables are
missing an id column.
Any ideas? It there a way to do this? Or do I need to write the
code 4 times in both the component and the eos?
Hey Andrew,
I thought about this on the way home today, and I think this is a
case of while they appear to be subclasses, they are indeed separate
classes just with several attributes (all but the PK) in that are
the same. This is pretty odd from an OO-point-of-view, but it is
taking a view to coerce the actual tables into something seemingly
related in the first place.
It might make sense in pure-OO land, but EOF adds some restrictions of
its own. It really does need a consistent PK for the super and all
sub-classes.
Unfortunately it looks like you will be duplicating the code in
several places, unfortunately. :-(
An interface for the 12 columns and a facade for the calculations
should reduce the amount of duplication needed.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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