> From: Colin Canfield [mailto:[EMAIL PROTECTED]]
> Subject: [Xdoclet-user] target-relation ?
> 
> 
> A quick question as to what is the target-relation tag ? It 
> is mentioned the
> 1.2 docs as a reference to use instead of jboss.relation but it isn't
> documented anywhere that I can find ?

There are several cases, hopefully this explains them better.  They were
somewhat confusing for me to start with as well.  Starting with a given
source entity and the target on the other side of a relation, there are 1:1,
1:n, n:1, and n:n relations. 

Internally to XDoclet, a relation is tracked separately of either side of the
relation using the name attribute of ejb:relation.  If both sides of a
relation have an @ejb:relation tag with a matching name attribute (the "name"
attribute is the key that is used to uniquely identify the relationship),
information that would otherwise be incomplete can be inferred.  But when the
target relation does not have corresponding reverse visibility of the source
in the relation and there is no @ejb:relation tag in the target with a
matching name attribute, there are *some* cases where additional information
needs to be provided to XDoclet in lieu of the missing information.  The
@ejb:target-relation tag provides the ability to provide this information.
Thus, it is only needed or used when there is one-way visibility on a
relation and the information that would normally be provided at the target is
critical to the complete set of information that is necessary to generate the
information about the relation as a whole.

The primary case of where this is necessary is where you have an 1:n
unidirectional link (there is no link visibility on the n side of the link).
Since 1:n links are modeled with the n side keeping a foreign key reference
of the 1 side, attempting to generate a 1:n link without reverse visibility
leaves XDoclet without the critical information it needs to know: the
related-pk-field attribute.  Using the target-relation tag allows this
information to be provided.  It's possible to model a 1:1 link this way,
where the schema visibility is target-to-source, but the desired design
visibility is source to target (for example, creating a new application on
top of a legacy schema.)  In this case the target-relation tag is used to
describe the schema details, even though the generated APIs are reversed of
that and under normal 1:1 circumstances, it would be fine to store the
foreign key in the source entity.

n:n and n:1 relations are the easy cases, because the source entity contains
the foreign key of the related entity.  Whether or not there is reverse
visibility is irrelevant to XDoclet since it has all the information it needs
about the relation in the ejb:relation tag.

HTH,

-b


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Reply via email to