You lost me. The relationships use referential integrity rules, which means that if A1->B1 then B1->A1. You can NOT have A1->B1 and B1->A2.
Did that answer you question?
No, I think I am after something simpler than that.
A1 -> B1
A2 -> B2
A3 -> B1
A4 -> B1
where object B does not know of the existence of object A, and therefore does not require a knowledge of the relationship.
In this case does JBoss consider this a 1-1 mapping, or a 1-n mapping ?
CMP 2.0 looks at this relationship as 1-1 unidirectional.
I think is is independent of web app servers, your case is clearly an 1:N relationship, not an 1:1 one. So you need here an 1-n mapping.
> A1 -> B1
> A2 -> B2
> A3 -> B1
> A4 -> B1
> where object B does not know of the existence of
> object A, and therefore does not require a knowledge
> of the relationship.
> In this case does JBoss consider this a 1-1 mapping,
> or a 1-n mapping ?
Directionality of relationships has nothing to do with the internal datastructures. Related objects always know about each other, and this is requried to enforce referential integrity. Anyway, you clearly have a n:1 unidirectional relationship (notice I wrote n:1 and not 1:n).
The reason I am asking this question is that I have a problem where I have a 'n:1' relationship which is performing a load of a very large table because it is basically loading the entire A table attempting to 'referential integrate' the appropriate 'B' instance.
Not only is this killing the system, but as it is a uni-directional association, in terms of the application it is unnecessary.
We have added a patch to JDBCCMRFieldBridge to only load the relationship when the metadata for the relationship contains a cmr-field entry. This check has been made in front of the 'load' calls within the setInstanceValue, getInstanceValue, and addRelation methods.
So far, the modification has passed the test suite, and has removed the reverse relationship load where it is not necessary.
Can you see any problems with this approach ?
I don't seen any problems (off the top of my head). I did work on a patch like this before and it ended up not working but I don't remember why. Maybe you got it right this time. I'll check it out later this week.