I think I understand what you are doing.  Since GenericValueObject its not
stated in the mapping file, both subclasses must repeat the inherited fields
and don't take advantage of the "extends" feature of Castor JDO.

In my case, I have a concrete super-class and subclasses that extend it. The
superclass has a class mapping in JDO.  The subclasses need to modify
columns in the same table that the superclass doesn't know about.  I was
hoping to leverage the "extends" feature so I don't have to propagate the
shared fields to each class.  If I use the extends class attribute Castor
tries to insert twice into the same table which fails.  I was hoping that a
future version of Castor could recognize that the both classes are mapped to
the same table and the insert for the subclass would be all the fields in
both class mappings.

-- Don


-----Original Message-----
From: Keith Chew [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 10, 2002 5:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Inheritance - Map two classes to One table



Hmm, interesting. I used to have a GenericValueObject, which is inherited by
value objects, eg UserVo, RoleVo, etc.

Object Level Design
The GenericValueObject is abstract and contains several common attributes,
eg id. UserVo, RoleVo all inherit from it.

Relational Level Design
user_table, role_table all have id as a field.

Castor Mapping
There's no maping for GenericValueObject since it does not map to a table.
Instead, declare the id in a the subclasses objects, eg UserVo has a id
field mapping.

XDoclet Configuration
If you are using Xdoclet, you need to declare the persistent fields in the
class's methods. Since GenericValueObject is not mapped to a table, you
declare your Xdoclet tags in the subclass objects, under a dummy (not dummy,
but an undeclared method) method.

Is is a typical case of denormalisation.

Good luck
Keith


-----Original Message-----
From: Don DeLuca [mailto:[EMAIL PROTECTED]]
Sent: Friday, 11 January 2002 11:12 a.m.
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Inheritance - Map two classes to One table


Are there any plans to support this in the near future.

In many cases, the developer doesn't have the choice of using multiple
tables to support inheritance. (e.g. A data modeler or DBA creates the
physical model)

-- Don



-----Original Message-----
From: Bruce Snyder [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 06, 2002 12:34 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Inheritance - Map two classes to One table


This one time, at band camp, Thomas Yip said:

TY >No
TY >>
TY >>Is it possible to map two classes to one table.
TY >>( i.e. Super and the Sub Class )

Thomas,

I thought that it was possible to map more than one class to one
table.

Say you've got a 30 column table that was originally designed by a
DBA as a catch-all table (for whatever reason). Now I am working
on a project and all the data I need for this phase of the project
is located in that 30 column table. Logically, this data can be
broken out into five or six top level classes. Is it not possible
at all the map these classes to this one table?

I seem to remember reading something or speaking with Oleg about
this very thing and it being possible. The reason I'm asking is
that I don't have the time to test this myself right now so I figured
I'd just ask a quick question.

Thanks!
Bruce
--

perl -e 'print
unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to