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
