db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Samson" <e...@xcalia.com>
Subject RE: Associations with attributes/roles
Date Sun, 26 Feb 2006 16:04:35 GMT
Erik,

I agree we could always find a mapping that would solve that particular
case.
But should we do it?

IMHO their design is not very clean.
 
It seems that in their business model there are several kinds of address
(two at the moment, why not 3 or more, later). 
This is something that is well captured in their database model, through the
notion of "type" which naturally maps with inheritance in object models.

But if they don't want to have subclasses in Java, then they should have a
collection of Address objects in Person, and they simply add a "type"
attribute in the Address class. 
At that time I agree it becomes more tedious to find one given type of
address of a Person.
Either they create access methods (e.g. getWorkAddress()) which will perform
a query filtering the type, or they can use Map of addresses in Person with
the type of Address being the key. 
This kind of mapping is supported by various ORM (XIC at least).

Best Regards
....: Eric Samson, Founder & CTO, Xcalia
SOA made easy through data & services intermediation

-----Message d'origine-----
De : erik@jpox.org [mailto:erik@jpox.org] 
Envoyé : vendredi 24 février 2006 19:00
À : 'Apache JDO project'; 'JDO Expert Group'
Objet : RE: Associations with attributes/roles

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 <eric@xcalia.com>:

> 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 : erik@jpox.org [mailto:erik@jpox.org]
> 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
>
>





Mime
View raw message