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 22:26:49 GMT
Erik

I always explain that EJB3 persistence is a subset of JDO2 in terms of
features. EJB3 is focused on ORM while JDO2 is universal.
I also explain the JDO2 contract is more constraining for vendors thus more
valuable for users.

I think most JDO2 vendors will also support EJB3.
It does not imply they will drop their JDO2 support (at least I hope it).
I still see many prospects really interested in JDO2 and we should all thank
the JPOX team for the nice job they did in delivering a good quality open
source JDO2 implementation.

With the emergence of SOA and light app servers (Spring ...), maybe EJB3
will die with the whole EJB stuff (notonly the persistence)? Who knows?

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é : dimanche 26 février 2006 20:19
À : 'Apache JDO project'; 'JDO Expert Group'
Objet : RE: Associations with attributes/roles

Eric,

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

IMO, yes. In the past, I perceived JDO been promoted to cope with any model.
I
propose this mapping be standardized in future releases, of course, if
vendors
will continue to invest in JDO, JPOX will. Nowadays, the hype is EJB3.

> This kind of mapping is supported by various ORM (XIC at least).

Glad to see XIC is spearheading the ORM field.

Quoting Eric Samson <eric@xcalia.com>:

> 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