Finally, we are on the same page ..not even a blue moon ...

Yup this is a suggestion. I agree 100% we need to avoid using 
jbosscmp-jdbc.xml.


Ulitmately at the database level for each table there has to be a unique 
  column name(s) that acts as a foreign key for the relation. It also 
can only participate in 1 relation.

For a many to many relationship with a mapping table could be a problem 
if the field name on both sides of the relationship were the same. But I 
would see this as an exception not the rule.

For self joins you would have to do like you do in the EJBQL and prefix 
the column with the table name. Not a bad idea for all relations so

select uuid from CDTrack where composer=?

would be

select c.uuid from CDTrack as c where c.composer=?



Dain Sundstrom wrote:

> Ok stop for a second.
> 
> Do you have a jbosscmp-jdbc.xml file that specifies the relationship should
> be mapped to a foreign key field named composer? If yes, then this is a bug.
> If no, then this is a suggestion.
> 
> If it is a suggestion, say so, and I will consider it.  My main goal when
> creating column names it to always allow an ejb jar to deploy without
> requiring a jbosscmp-jdbc.xml file.  When explaining the suggestion explain
> why you would not get a name collision.
> 
> -dain
> 
> 
>>-----Original Message-----
>>From: Dave Smith [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, November 16, 2001 12:22 PM
>>To: Dain Sundstrom
>>Cc: [EMAIL PROTECTED]
>>Subject: Re: [JBoss-dev] 1 to Many Relations
>>
>>
>>When it tries to load the CDTrack relation it generates the following 
>>sql statement ..
>>
>>select uuid from CDTrack where composer_composed_songs=?
>>
>>should be ..
>>
>>select uuid from CDTrack where composer=?
>>
>>
>>Dain Sundstrom 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?
>>>>
>>>>
>>>>
>>>
>>>So what is the problem?  Table mapping is an implementation 
>>>
>>detail.  Does
>>
>>>the above not deploy?  Is ejb-doclet generating bad ddl?
>>>
>>>-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

Reply via email to