Armin,

Looks like the test case ConvertedKeyReferenceTest might be broken. 

Lines 69 and 90 test for pk of ConversionReferrer being converted. If you look at the 
repository_junit.xml the pk field for ConversionReferrer does not have a conversion 
attribute.

Also, neither ConvertedKeyReferenceTest nor FeildConversionForeigenKeyTest cover the 
case where key conversion is not happening for primary key for an object that is 
created. Think this was broken by change in rev 1.12 of Identity. 

In ConvertedKeyReferenceTest there is a case covering this issue. Not sure why it 
dosen't pick up the failure, but one theory is the nature of the test. The class 
TestInt2IntConverter flip flops values. It might better to do destructive but 
predictable damage to the value, rather than a flip flop.  Flip flop will only really 
detect failure to convert in one direction, not both! Another strategy to test might 
be to force a class cast exception if conversion doesn't occur.

I do know I need to patch Identity for the normal case of CRUD for an object with a pk 
that requires conversion. What I don't know is what bad side effects this causes. I 
think cleaning up the test cases first would help to find out.

Looking for input. If you think it is worthwhile, I can come up with a test for PK 
conversion that will detect bi-directional failure. Just uncertain what the scenario 
is for reliably testing double conversion. Not sure if the test in 
ConvertedKeyReferenceTest for this is correct.

Finally, would be nice to rename the file FieldConversionForeigenKeyTest to 
FieldConversionForeignKeyTest. It is mispelled.

Let me know what you think. Will be glad to tackle this if you like.

Index: Identity.java
===================================================================
RCS file: /home/cvspublic/db-ojb/src/java/org/apache/ojb/broker/Identity.java,v
retrieving revision 1.14
diff -r1.14 Identity.java
195,196c195
<                 // BRJ: do not convertToSql
<                 this.pkValues = targetBroker.serviceBrokerHelper().getKeyValues(cld, 
objectToIdentitify,false);
---
>                 this.pkValues = targetBroker.serviceBrokerHelper().getKeyValues(cld, 
> objectToIdentitify);

> -----Original Message-----
> From: Armin Waibel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 19, 2003 6:32 AM
> To: OJB Developers List
> Subject: [OJB test failures] some really nasty bugs
> 
> 
> Hi all,
> 
> I add some new test cases posted by Users (thanks Charles, Oliver and
> all I forget)
> and do some modifications to point out the problems (I hope so;-)).
> 
> 1. UserTestCases
> Test testImplicitLocking() fail when implicit locking was set to
> 'false',
> the test pass when implicit locking was 'true'.
> The test change the 'useImplicitLocking' property to 'false'
> to simulate the situation.
> 
> 2. FieldConversionForeignKeyTest/ConvertedKeyReferenceTest
> This was the really nasty bug!
> Both test cases use field conversions. It seems that in some cases
> PK fields are not converted.
> 
> For example in StatementManager#bindSelect(...) method, the given
> Identity object seems to wrap unconverted pk values, when I do a
> field conversion in this method all seems ok, but now in some cases
> the field conversion was done twice (ConvertedKeyReferenceTest)
> on the same values. This is tragic when using a field conversion
> like TestIntToIntConverter.
> 
> I think one part of the problem could be Identity, because it is
> possible to make Identity instances with converted pk values
> and without!
> new Identity(Object objectToIdentitify, PersistenceBroker 
> targetBroker)
> --> without conversion
> new Identity(Class aClass, Object[] CONVERTEDpkValues)
> --> with converted pk valuse
> 
> Any suggestions?
> 
> regards,
> Armin
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to