Eric,
That's the same workaround I proposed to the user. Although, I still think
forcing the user to define subclasses is not the ideal solution since it is
just a mapping issue.
Quoting Eric Samson <[EMAIL PROTECTED]>:
> To me it could be managed as a kind of inheritance.
>
> class Person {
> String name;
> HomeAddress home;
> WorkAddress work;
> ...
> }
>
> Both HomeAddress and WorkAddress are subclasses of an abstract class Address
> and are stored in the same table with ADDR_TYPE defined as the
> discriminating column.
>
> What do you think?
>
> Best Regards,
> ....: Eric Samson, Founder & CTO, Xcalia
> SOA made easy through data & services intermediation
>
> -----Message d'origine-----
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Envoyé : vendredi 24 février 2006 11:01
> À : Apache JDO project; JDO Expert Group
> Objet : Associations with attributes/roles
>
> An user sent us this, which might be a nice addition for a future JDO
> release.
>
> An outline of his wish is 1-1 or 1-N associations with properties allowing
> to
> distinguish from other associations to same types. A kind of discriminator
> at
> field level.
>
> Regards,
> -------------
> I have checked docs looking for examples but with no
> success.
> Recalling a typical example of a person with 2 addresses,
> defined as distinct members of Person class,
> I would map the Address class in a table with a FK to Person
> and some extra (constant) column as discriminator.
>
> class Person {
> String name;
> Address home;
> Address work;
> ...
> }
>
> Address {
> String street;
> String city;
>
> ..
> }
>
> Table PERSON
> -----------------
> PERSON_ID
> NAME
>
> Table ADDRESS
> -------------------
> ADDRES_ID
> STREET
> CITY
> PERSON_ID
> ADDR_TYPE = {"HOME", "WORK"}
>
> ADDR_TYPE values should be transparently managed by
> JDO implementation
>
> Is it possible with jpox standard/extensions ?
> Is it possible for collections too (i.e. 2 addresses collections) ?
>
> Guido
>
>
