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 <[EMAIL PROTECTED]>: > 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 : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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 <[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 > > > > > > > > >
