Unidirectional also implies knowledge. So the Requirement shouldn't really know about the Project to which it belongs. Is it a big deal - nah, I wouldn't be too bothered if it was implemented the way you say, although I'd prefer my way.
As to changing the schema - well if the schema already supports the relationship, fine, use that - if it doesn't then a schema change is inevitable. Edward On 5/10/03 11:30 am, "Daniel Lopez" <[EMAIL PROTECTED]> wrote: > 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 ------------------------------------------------------- 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
