db-ojb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Grosse <gerhard.gro...@lex-com.net>
Subject Re: Java class for ordering SQL statements in ODMG to avoid FK violations
Date Fri, 19 Nov 2004 08:14:27 GMT
Hi Jakob,

On Fri, 19 Nov 2004 08:20:53 +0100 (MET), "Jakob Braeuchi" <jbraeuchi@gmx.ch>
wrote:

>hi armin,
>
>in the testcase i mentioned the auto-update is set to LINK. 
>does the scenario you describe also work for odmg ? i was thinking of
>something similar in PB: the PB keeps track of the mn-implementors to be
>inserted and inserts them when the main objects are in the tables.
>

If something like this could be realalized at PB level, it would remove the need
for any ordering of m:n related objects. And this would in turn further reduce
the probability of contradicting constraints. Note that of course deletions in
the link table would have to occur before any deletion / update of the main
objects.

BTW, are the remaining failing test cases all in M2NTest and due to the
bidirectional m:n relationship? I ran my tests against version 1.0.1 and got
only the 2 failures in org.apache.ojb.odmg.CollectionsTest
(testRemoveCollectionElementWithoutBackReference and
testStoreDeleteCollectionElementWithBackReference) which also failed with the
original ordering.

Gerhard

>gerhards new class correctly orders the objects to be inserted, but cannot
>control the settings of auto-update. so the first obj inserted tries to
>update the indirection-table.
>
>jakob
>
>> Jakob Braeuchi wrote:
>> 
>> > hi gerhard,
>> > 
>> > the failing testcases in org.apache.ojb.odmg.M2NTest can not at all be 
>> > fixed by reordering.
>> > 
>> > the problem is the bidirectional m:n relationship with auto-update = 
>> > LINK on both sides. no matter what side is inserted first pb tries to 
>> > insert into the indirection-table as well. this will always fail.
>> > setting auto-update to OBJECT does also not help in this case because 
>> > objects are inserted more than once which leads to a unique key
>> violation.
>> > 
>> > the only solution i see is to _defer_ the insertion of the 
>> > indirection-table until all main objects are saved. unfortunately i have
>> > no idea how to do this :(
>> >
>> 
>> hmm, if we change auto-update to NONE (instead false) for m:n relations, 
>> insert/update both sides, "mark" these objects with m:n relation for 
>> postprocessing and then populate the Indirection Table by using 
>> PBImpl#linkMtoN(Object obj, CollectionDescriptor cod, boolean insert).
>> Note: I never tried this ;-)
>> 
>> regards,
>> Armin
>> 
>> 
>> > jakob
>> > 
>> > Jakob Braeuchi schrieb:
>> > 
>> >> hi gerhard,
>> >>
>> >> thanks for your contribution. it looks really impressive !
>> >> i integrated your class into to current 1.0.x branch an ran all odmg 
>> >> testcases without skipping known issues.
>> >> with the old reorder i get:
>> >>
>> >> Tests run: 207,  Failures: 2,  Errors: 8
>> >>
>> >> with your ordering i still have 6 errors:
>> >>
>> >> Tests run: 207,  Failures: 2,  Errors: 6
>> >>
>> >> ie this one:
>> >>
>> >> 3) 
>> >>
>>
>testStoreComplex(org.apache.ojb.odmg.M2NTest)org.apache.ojb.odmg.TransactionAbortedExceptionOJB
>
>> >>
>> >>     at 
>> >>
>>
>org.apache.ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:174)
>
>> >>
>> >>     at 
>> >>
>>
>org.apache.ojb.odmg.TransactionImpl.doWriteObjects(TransactionImpl.java:324)
>
>> >>
>> >>     at 
>> >> org.apache.ojb.odmg.TransactionImpl.prepare(TransactionImpl.java:624)
>> >>     at 
>> >> org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:581)
>> >>     at org.apache.ojb.odmg.M2NTest.doTestStoreComplex(M2NTest.java:157)
>> >>     at org.apache.ojb.odmg.M2NTest.testStoreComplex(M2NTest.java:137)
>> >>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >>     at 
>> >>
>>
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
>> >>
>> >>     at 
>> >>
>>
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
>> >>
>> >>     at org.apache.ojb.odmg.AllTests.main(AllTests.java:18)
>> >> Caused by: org.apache.ojb.broker.OJBRuntimeException: Given object 
>> >> collection of type class 
>> >> org.apache.ojb.odmg.M2NTest$MovieManageableCollection can not be 
>> >> managed by OJB. Use Array, Collection or ManageableCollection instead!
>> >>     at 
>> >>
>>
>org.apache.ojb.odmg.ObjectEnvelopeOrdering.addCollectionEdges(ObjectEnvelopeOrdering.java:312)
>
>> >>
>> >>     at 
>> >>
>>
>org.apache.ojb.odmg.ObjectEnvelopeOrdering.addEdgesForVertex(ObjectEnvelopeOrdering.java:241)
>
>> >>
>> >>     at 
>> >>
>>
>org.apache.ojb.odmg.ObjectEnvelopeOrdering.reorder(ObjectEnvelopeOrdering.java:133)
>
>> >>
>> >>     at 
>> >>
>>
>org.apache.ojb.odmg.ObjectEnvelopeTable.reorder(ObjectEnvelopeTable.java:588)
>
>> >>
>> >>     at 
>> >>
>>
>org.apache.ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:148)
>
>> >>
>> >>
>> >> jakob
>> >>



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


Mime
View raw message