I think that that makes sense to use common tags to do common things. For
relational database mapping in particular, the same strategies are used for
mapping an ejb to a table or a jdo class to a table, except when we're
speaking of object identity or some advanced mapping stragegies like
inheritance, mapping a java field to more than one column....
For the JDO mapping, i have defined so far the following (replace
@jdo.rdbmapping by @sql if you wish):
Java field to table column:
/**
* @jdo.rdbmapping table-name="reservations"
*/
class Reservation {
/**
* The reservationId field
* @jdo.field
* @jdo.rdbmapping column-name="reservation_id"
*/
private int reservationId;
}
1:1 relationship
class Reservation {
/**
* This is a bi-directional one-to-many relationship for relation
flights-sunjdo10-reservations-sunjdo10 <br>
* The related FlightBean
*
* @jdo.field
* modifier="persistent"
* @jdo.rdbmapping
* column-name="flight_id_fk"
* related-field="flightId"
*
*/
private airline.jdo.FlightBean flight = null;
}
1:n relationship
On the 1 side:
class Person {
/**
* This is a bi-directional one-to-many relationship for relation
persons-sunjdo10-reservations-sunjdo10 <br>
* The collection of related ReservationBean
*
* @jdo.field collection-type="collection"
element-type="airline.jdo.ReservationBean"
* @jdo.rdbmapping-relation
* related-field="person"
* style="foreign-key"
*/
private java.util.Collection reservations = new java.util.HashSet();
}
On the n side:
class Reservation {
/**
* This is a bi-directional one-to-many relationship for relation
persons-sunjdo10-reservations-sunjdo10 <br>
* The related PersonBean
*
* @jdo.field
* modifier="persistent"
* @jdo.rdbmapping
* column-name="person_id_fk"
* related-field="personId"
*
*/
private airline.jdo.PersonBean person = null;
}
n:m relationship with a relation table:
class Person {
/**
* This is a bi-directional many-to-many relationship for relation
flights-sunjdo10-persons-sunjdo10 <br>
* The collection of related FlightBean
*
* @jdo.field collection-type="collection"
element-type="airline.jdo.FlightBean"
* @jdo.rdbmapping-relation
* related-field="persons"
* style="relation-table"
* table-name="reservations"
* @jdo.rdbmapping
* column-name="person_id_fk"
* related-field="personId"
*/
private java.util.Collection flights = new java.util.HashSet();
}
class Flight {
/**
* This is a bi-directional many-to-many relationship for relation
flights-sunjdo10-persons-sunjdo10 <br>
* The collection of related PersonBean
*
* @jdo.field collection-type="collection"
element-type="airline.jdo.PersonBean"
* @jdo.rdbmapping-relation
* related-field="flights"
* style="relation-table"
* table-name="reservations"
* @jdo.rdbmapping
* column-name="flight_id_fk"
* related-field="flightId"
*/
private java.util.Collection persons = new java.util.HashSet();
}
where you can recognize the Middlegen samples. Feedback on the design of
those tags is welcome.
Here i assume that relationships are bidirectional, so if some infomation is
missing on one side of the relationship, i get it from the other side, and
that's why you need a related-field attribute. This is particularly obvious
on the n:m relationship where only the mapping between one table and the
relation table is described, and the rest is ignored since it will be
described on the other side.
Aslak idea would make it easier to share the common mapping strategies used
for CMP persistence or JDO persistence. Since you have vendors like Toplink
who already support both EJB and (partially) JDO with the same product, i
think it is quite possible to do it.
Ludovic
PS: weblogs look interesting, so i have started my weblog on
http://ludo.blog-city.com and hope to put cool ideas there.
----- Original Message -----
From: "Aslak Hellesøy" <[EMAIL PROTECTED]>
To: "David Jencks" <[EMAIL PROTECTED]>; "xdoclet-devel"
<[EMAIL PROTECTED]>
Cc: "Ludovic Claude" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, October 18, 2002 12:10 AM
Subject: RE: [Xdoclet-devel] How many jdo modules do we need? One per
vendor?
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:xdoclet-devel-admin@;lists.sourceforge.net]On Behalf Of David
> > Jencks
> > Sent: 17. oktober 2002 18:39
> > To: xdoclet-devel
> > Subject: [Xdoclet-devel] How many jdo modules do we need? One per
> > vendor?
> >
> >
> > Hi,
> >
> > Ludovic Claude submitted some nice subtasks for doing vendor extensions
in
> > the jdo module. He's written them as a separate module for each
> > jdo vendor
> > (currently 2, LiDO and Solarmetric/KODO) More are sure to come soon (I
> > have to write one for tjdo). These vendor specific subtasks are going
to
> > have about 2 files each.
> >
> > Do we want them as a separate module for each vendor or should they all
go
> > under the jdo module?
> >
>
> I think they should be kept as distinct modules. The new architecture (in
> the xdoclet2 CVS module) will have a one-one relationship between
<subtask>
> and plugin directory. (plugin is the new name for module). One per vendor.
>
> > At a more fundamental level, he's implemented these based on tags like
> >
> > @kodo.table
> >
> > I think a lot of these tags will be essentially the same for all jdo
> > implementations based on rdbms. I wonder if we should try to be more
> > universal, like
> >
> > @jdo table="blah"
> >
> > or even
> >
> > @jdo persistence-location="blah"
> >
> > Any comments?
> >
>
> I do :-)
>
> I participated in some email discussions a few days ago with the people on
> cc here about representing "database metadata" as tags. I wrote some words
> about this in my blog: http://roller.anthonyeden.com/page/rinkrank/.
Scroll
> down to "Synergy!!" and read the last part of that post.
>
> My point is that I think we should settle on something even more generic
> than @jdo and @ejb, because the information we put in these tags is the
> same. IMO it should be @sql, @jdbc or @rdbms.
>
> Further, I think we should stick to namespaces (dotted tag names) for the
> sake of consistency. Who knows, they might have a programmatic sense one
> day, and it would be a shame if we invented lots of "namespace-less" tags.
> My suggestion is therefore:
>
> Instead of
> @ejb.persistence table-name="blah"
> @jdo table="blah"
>
> We could go for
> @sql.table name="blah"
>
> Then who knows, maybe you can write a simple java bean, and let XDoclet
> decide whether it should turn it into a JDO, EJB or some other
> persistent-aware class.
>
> This is kind of the way I think when I do OO programming. Anything generic
> that can be used in different scenarios deserves its own class. It should
be
> the same way for @tags, and I think this is a perfect example for that.
>
> We already have a (albeit dirty) mechanism for supporting BWC on the tag
> level, and this can be made better in xdoclet2.
>
> What do you think?
>
> > thanks
> > david jencks
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: viaVerio will pay you up to
> > $1,000 for every account that you consolidate with us.
> > http://ad.doubleclick.net/clk;4749864;7604308;v?
> > http://www.viaverio.com/consolidator/osdn.cfm
> > _______________________________________________
> > Xdoclet-devel mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
>
-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
