Hi,
It that's correct, then I haven't understood what unidirectional and
bidirectional means. From what I got, one thing is the cardinality of the
relationship (one-many or many-many) and another thins is if you want to be able
to "travel" the relationship from both sides or just from one side to the other
(bidirectional or unidirectional). If having the relationship unidirectional
forces you to modify your db schema, then I would not call it a good practice as
, IMHO, the "wrapper layer" should not dictate how you store your data.
Following you example, I still don't see why you can't store the project PK in
the requirement table. If one requirement belongs to one and only one project,
then that's the best place to store it. The fact that you cannot "travel" the
relationship one way or the other is, AFAIK, irrelevant. You can use
target-multiple to say if you are accessing one or many, you add the target-ejb
property accordingly and the container specific tag to set the foreign key
column and you have all the data you need. May be from the Java layer the other
side of the relationship is <undefined>, but that does not mean you have to
force it to be undefined in your DB schema.
Actually, if you have a look at the XDoclet samples, the EJB CMR ones, there's a
Country bean that has a 1-N unidirectional to the City Bean. The DB schema that
comes with the samples has the country_id_fk inside the city table. The
relationship is modelled with XDoclet like that:
/**
* Returns a collection of related test.ejb.cmr.CityLocal
*
* @return a collection of related test.ejb.cmr.CityLocal
* @ejb.interface-method
* view-type="local"
* @ejb.relation
* name="city-country"
* role-name="country-has-city"
* target-ejb="City"
* target-multiple="no"
* target-role-name="city-has-country"
* @weblogic.target-column-map
* foreign-key-column="country_id_fk"
* @jboss:target-relation
* related-pk-field="countryId"
* fk-column="country_id_fk"
*/
public abstract java.util.Collection getCities();
and the the tables look like...
CREATE TABLE country(
country_id INT NOT NULL,
...
PRIMARY KEY( country_id ),
...)
CREATE TABLE city(
city_id INT NOT NULL,
country_id_fk INT NOT NULL,
...
PRIMARY KEY( city_id ),
FOREIGN KEY (country_id_fk) REFERENCES country(country_id)
...)
I hope it helps,
D.
> Because if it's bidirectional, 1 project has many requirements for example,
> then you store the project PK in the associated requirement table as a
> foreign key. If it's unidirectional then you can't store the Project pk in
> the requirement table. Strictly speaking 1 to many, and many to many,
> unidirectional are actually <undefined> to many.
>
> On 2/10/03 11:30 am, "Daniel L�pez" <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> > Do you really need an extra table when creating a unidirectional 1-n
> > relationship? I've always used bidirectional relationships so I've never
> > tried, but I don't see the reason why unidirectional ones would require
> > such an extra table. May be I did not understand the statement below.
> > Cheers,
> > D.
> >
> > Edward Kenworthy escribi�:
> >> This is a unidirectional 1:m so yes you do need a relationship table.
> > ... //snipped
--
This message was sent using Sake Mail, a web-based email tool from
Endymion Corporation. http://www.endymion.com/products/sake
Because if it's bidirectional, 1 project has many requirements for example,
then you store the project PK in the associated requirement table as a
foreign key. If it's unidirectional then you can't store the Project pk in
the requirement table. Strictly speaking 1 to many, and many to many,
unidirectional are actually <undefined> to many.
On 2/10/03 11:30 am, "Daniel L�pez" <[EMAIL PROTECTED]> wrote:
> Hi,
> Do you really need an extra table when creating a unidirectional 1-n
> relationship? I've always used bidirectional relationships so I've never
> tried, but I don't see the reason why unidirectional ones would require
> such an extra table. May be I did not understand the statement below.
> Cheers,
> D.
>
> Edward Kenworthy escribi�:
>> This is a unidirectional 1:m so yes you do need a relationship table.
> ... //snipped
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
