Hi,
p b wrote:
Yes Armin,
we have never tested the inverse relation from Organization to Profile,
but with the correction in Organization I've the same problem of duplicated key.
If I change the auto-XXX into Profile to
auto-retrieve="true"
auto-update="false"
auto-delete="false"
in Profile you are using auto-retrieve="true" auto-update="true" auto-delete="link"
so try the same settings in Organisation. Or try auto-retrieve="true" auto-update="object" auto-delete="object" in both collection-descriptor first (most tested settings) and then auto-retrieve="true" auto-update="object" auto-delete="link"
There are several test cases in OJB test-suite using m:n relations (e.g. M2NTest.java) all tests for PB-api pass. Check the <fk-pointing-to-... settings and check for abandoned entries in indirection table (if you don't use DB constraints)
regards, Armin
the relation does not rise the exception, but (obviusly) have a wrong behavior.
I suppose the above settings are correct, then ==>
Organization:
....
<collection-descriptor name="users" element-class-ref="it.gesi.userprofiling.Organization"
#### ==> shouldn't it be Profile?
collection-class="org.apache.ojb.broker.util.collections.ManageableVector"
auto-retrieve="true" auto-update="false" auto-delete="false" ### ==> try same settings as above first
indirection-table="dps_user_org"> <fk-pointing-to-this-class column="user_id"/> <fk-pointing-to-element-class column="organization"/> ### ==> should be vice versa
</collection-descriptor>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
