I know. The point is as far as I am concered this is the most basic of cases. We want to avoid users having to know jboss'isms unless they are doing something quite weird.
Dmitri Colebatch wrote: > You can set a different column name using @jboss:column-name (see > http://xdoclet.sourceforge.net/jboss.html#column-name) > > cheers > dim > > On Fri, 16 Nov 2001, Dave Smith wrote: > > >>I'm using xdoclet to generate the ejb-jar.xml file. When you are >>generating the accessor methods it automaticly assumes that the accessor >>name matches the database column name. So in your example by default it >>is looking for a database columns named composer and performer. >> >>This is a packaging issue, ie how much work and how confusing is it to >>generate the ejb-jar.xml files. From my point of view I think that the >>simplist case is that each database column has a matching get/set method >> . So in xdoclet .. >> >>Musician { >> >> String name; // pk >> /** >> @ejb:persist-field >> @ejb:relation name="songs_composer" >> */ >> Collection getComposedSongs(); >>} >> >>CDTrack { >> String uuid; // pk >> /** >> @ejb:persist-field >> @ejb:relation name="songs_composer" >> */ >> Musician getComposer(); >>} >> >>Generates >><ejb-relation> >> <ejb-relation-name>songs_composer</ejb-relation-name> >> >> <ejb-relationship-role> >> <multiplicity>Many</multiplicity> >> <relationship-role-source> >> <ejb-name>CDTrack</ejb-name> >> </relationship-role-source> >> <cmr-field> >> <cmr-field-name>composer</cmr-field-name> >> </cmr-field> >> </ejb-relationship-role> >> >> <ejb-relationship-role> >> <multiplicity>One</multiplicity> >> <relationship-role-source> >> <ejb-name>Musician</ejb-name> >> </relationship-role-source> >> <cmr-field> >> <cmr-field-name>CDTrack</cmr-field-name> >> <cmr-field-type>java.util.Collection</cmr-field-type> >> </cmr-field> >> </ejb-relationship-role> >> >> </ejb-relation> >> >>Tables .. >> >>Musician { >> String name; >>} >> >>CDTrack { >> String uuid; >> String composer; >>} >> >> >>Got it? >> >> >> >>Dain Sundstrom wrote: >> >> >>>>Dain Sundstrom wrote: >>>> >>>> >>>> >>>>>>OK i'm playing with the latest RH CVS and testing out 1 to many >>>>>>relations (bi directional). So .. >>>>>> >>>>>>Table1 { >>>>>>primary_key int, >>>>>>} >>>>>> >>>>>>TableMany { >>>>>>primary_key int, >>>>>>table1_key int, >>>>>>} >>>>>> >>>>>>class Table1 { >>>>>> int getPrimary_key() >>>>>> Collection getTableMany(); >>>>>>} >>>>>> >>>>>>class TableMany { >>>>>> int getPrimary_key(); >>>>>> int getTable1_key(); >>>>>>} >>>>>> >>>>>>the problem is that when it tries to fetch TableMany it looks for a >>>>>>field called table1_key_primary_key. It would seem that the >>>>>>default key >>>>>>should not be made up but the foreign key of the other side of the >>>>>>relationship. So line 80 of >>>>>> >>>>>> >>>>JDBCRelationshipRoleMetaData.java should >>>> >>>> >>>>>>just be >>>>>>tempCmrFieldName = relatedRole.getEntityName(); >>>>>> >>>>>> >>>>>> >>>>>> >>>>>1. Defaults can be overridden. >>>>> >>>>> >>>>> >>>>This is the default case. The strange cases should be >>>>overridden. Read >>>>Marc's bit about packaging. >>>> >>>> >>>What bit about packaging? >>> >>> >>> >>>>>2. What happens when you have two one-to-many relationships >>>>> >>>>> >>>>between Table1 >>>> >>>> >>>>>and TableMany? >>>>> >>>>> >>>>> >>>>Doesn't matter you still need Table1's primary key in >>>>TableMany. So you >>>>would have >>>> >>>>Table1 { >>>> Collection getTableMany(); >>>> Collectiont getTableMany2(); >>>>} >>>> >>>>TableMany { >>>>int getTable1_key(); >>>>int getTable2_2_key(); >>>>} >>>> >>>> >>>> >>>You have lost me. What is the problem? >>> >>>Let us clean up the example: >>> >>>Musician { >>> String name; // pk >>> Collection getComposedSongs(); >>> Collection getPreformedSongs(); >>>} >>> >>>CDTrack { >>> String uuid; // pk >>> Musician getComposer(); >>> Musician getPerformer(); >>>} >>> >>>You would get the following table: >>> >>>Musician { >>> name >>>} >>> >>>CDTrack { >>> uuid, >>> musician_composer_name, >>> musician_performer_name >>>} >>> >>>As you can see you get fk with the following pattern: >>> <related_entity_name>_<cmr_field_name>_<related_entity_pk_field_name> >>> >>>unless the many side does not have a cmr field for the relationshiop then >>>you get: >>> >>><related_entity_name>_<related_cmr_field_name>_<related_entity_pk_field_name >>> >>> >>>Or am I answering the wrong question? >>>-dain >>> >>> >>> >> >> >>_______________________________________________ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
