Armin Waibel wrote:
I forget to check in one class (MaterializationCache). Does it make a difference with the new version?

Nope, but it's the test that is defunct probably not the code. I checked in an updated version of the test to clarify my point of failure.


The two Gatherer objects are stored OK and then retrieved with this query:

"select gatherer from " + Gatherer.class.getName() + " where gatId=$1 or gatId=$2";

Using P6Spy I see that Oracle does:
SELECT A0.GAT_ID,A0.NAME FROM COLLECTION_GATHERER A0 WHERE A0.GAT_ID = '181' OR (A0.GAT_ID = '182')



There is no guarantee on the returned order of these items as long as there is no ORDER BY, GROUP BY or similar on the query. This testcase will not be reproducable as long as no order is guaranteed. (After doing some additional inserts or updates Oracle might decide to flip the two again, and it's got the right to do so.)


I don't speak ODMG query language so if you could maybe fix the query?

Previous failure was on Collection but that's just because no assert was made that "gat2" was in fact the second Gatherer. With my update to the testcase this is asserted and thus it fails earlier. I now get:
junit.framework.ComparisonFailure: Wrong gatherer returned: fetchedGat should be first Gatherer
Expected:
testUpdateWhenExchangeObjectsInCollection1111178759937_Gatherer
Actual:
testUpdateWhenExchangeObjectsInCollection1111178759937_Gatherer2


Regards,
 Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to