|
Home > Archive > Apache JDO Project > February 2006 > Associations with attributes/roles
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Associations with attributes/roles
|
|
| erik@jpox.org 2006-02-25, 5:46 pm |
| 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
| |
| erik@jpox.org 2006-02-25, 5:46 pm |
| 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
>
>
| |
| Eric Samson 2006-02-26, 5:45 pm |
| 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.
=20
It seems that in their business model there are several kinds of address
(two at the moment, why not 3 or more, later).=20
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.=20
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.=20
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=A0: erik@jpox.org [mailto:erik@jpox.org]=20
Envoy=E9=A0: vendredi 24 f=E9vrier 2006 19:00
=C0=A0: 'Apache JDO project'; 'JDO Expert Group'
Objet=A0: 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=E9 : vendredi 24 f=E9vrier 2006 11:01
> =C0 : 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 =3D {"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
>
>
| |
| erik@jpox.org 2006-02-26, 5:45 pm |
| 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>:
>
> Address
>
>
>
>
>
| |
| David Jordan 2006-02-26, 5:45 pm |
|
The hype is EJB3 because the EJB 3 community is busy writing articles =
about
it. Some I have read make it sound like object persistence is brand new,
such BS. Those backing JDO need to start writing articles about JDO 2.0 =
and
when EJB 3 is finalized, it would be great to have articles that do a
side-by-side comparison of the two standards.
David Jordan
Object Identity, Inc.
-----Original Message-----
From: erik@jpox.org [mailto:erik@jpox.org]=20
Sent: Sunday, February 26, 2006 2:19 PM
To: 'Apache JDO project'; 'JDO Expert Group'
Subject: 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.
| |
| karan malhi 2006-02-26, 5:45 pm |
| I totally agree. Also, those writing books should have an RDBMS backend
for examples. I have read books (and recommended to my students), which
are really really informative, but they dont show things like
configuring a db, mapping to a db(RDBMS) etc. I understand that this was
an issue earlier because mapping was more vendor specific. JDO 2 gives
an opportunity for book writers to show a complete end to end picture of
JDO.
David Jordan wrote:
>The hype is EJB3 because the EJB 3 community is busy writing articles about
>it. Some I have read make it sound like object persistence is brand new,
>such BS. Those backing JDO need to start writing articles about JDO 2.0 and
>when EJB 3 is finalized, it would be great to have articles that do a
>side-by-side comparison of the two standards.
>
>David Jordan
>Object Identity, Inc.
>
>
>-----Original Message-----
>From: erik@jpox.org [mailto:erik@jpox.org]
>Sent: Sunday, February 26, 2006 2:19 PM
>To: 'Apache JDO project'; 'JDO Expert Group'
>Subject: RE: Associations with attributes/roles
>
>Eric,
>
>
>
>
>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.
>
>
>
>
>
--
Karan Singh
| |
| Eric Samson 2006-02-26, 5:45 pm |
| 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=A0: erik@jpox.org [mailto:erik@jpox.org]=20
Envoy=E9=A0: dimanche 26 f=E9vrier 2006 20:19
=C0=A0: 'Apache JDO project'; 'JDO Expert Group'
Objet=A0: 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=E9 : vendredi 24 f=E9vrier 2006 19:00
> =C0 : '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>:
>
> Address
JDO[vbcol=seagreen]
allowing[vbcol=seagreen]
discriminator[vbcol=seagreen]
>
>
>
>
>
|
|
|
|
|