RE: OJB test failures
Jakob (and Armin and Thomas as well) Thank you very much for working through this! Andy -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Sunday, March 02, 2003 7:02 AM To: OJB Users List Subject: Re: OJB test failures Hi Jakob, great work!! regards, Armin - Original Message - From: Jakob Braeuchi [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Sunday, March 02, 2003 11:00 AM Subject: Re: OJB test failures hi thomas, field conversion should be ok now. all conversion testcases pass. i also fixed a minor glitch in collection proxy clear() which makes MtoNMmapping pass as well. jakob Thomas Mahler wrote: Hi all, Jakob Braeuchi wrote: hi andrew, i changed Identity to do a convertToSql when called with an object, no conversion takes place when called with pkValues. with this change all conversion test are passed. i have a version where conversion takes place during binding of the variables, but this version fails on the referrer test :( should we drop conversion of pk values completely ? There are several users that use some kind of GUID objects as primary key attributes. Those GUID need FieldConversions to be mapped to a (e.g.) VARCHAR column. So dropping this feature is not an option. We have to make sure that FieldConversions are properly applied for pk fields too. cheers, Thomas jakob Andrew Gilbert wrote: Armin, Thank you very much for this! I will build latest and re-test soon. The bummer is, it would be a major impediment to our use of OJB if we couldn't convert on pk fields. We use a custom GUID impl for the pk in many of our BO's and tables. Not sure I fully understand yet the Identity change. Sounds like you are saying internal state was inconsistent? ## I think the made changes are correct, because the conversion was not transparent for the user of the Identity object. I suggest never use converted (java -- sql) pk fields within Identity (I don't know if code base is comply with this suggest, maybe that's the reason for the hassle). The conversion could be done when it's necessary. But nevertheless I think there is a nasty bug when using field conversion with pk fields. - 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] - 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] - 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]
Re: OJB test failures
Hi all, Jakob Braeuchi wrote: hi andrew, i changed Identity to do a convertToSql when called with an object, no conversion takes place when called with pkValues. with this change all conversion test are passed. i have a version where conversion takes place during binding of the variables, but this version fails on the referrer test :( should we drop conversion of pk values completely ? There are several users that use some kind of GUID objects as primary key attributes. Those GUID need FieldConversions to be mapped to a (e.g.) VARCHAR column. So dropping this feature is not an option. We have to make sure that FieldConversions are properly applied for pk fields too. cheers, Thomas jakob Andrew Gilbert wrote: Armin, Thank you very much for this! I will build latest and re-test soon. The bummer is, it would be a major impediment to our use of OJB if we couldn't convert on pk fields. We use a custom GUID impl for the pk in many of our BO's and tables. Not sure I fully understand yet the Identity change. Sounds like you are saying internal state was inconsistent? ## I think the made changes are correct, because the conversion was not transparent for the user of the Identity object. I suggest never use converted (java -- sql) pk fields within Identity (I don't know if code base is comply with this suggest, maybe that's the reason for the hassle). The conversion could be done when it's necessary. But nevertheless I think there is a nasty bug when using field conversion with pk fields. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB test failures
hi andrew, i changed Identity to do a convertToSql when called with an object, no conversion takes place when called with pkValues. with this change all conversion test are passed. i have a version where conversion takes place during binding of the variables, but this version fails on the referrer test :( should we drop conversion of pk values completely ? jakob Andrew Gilbert wrote: Armin, Thank you very much for this! I will build latest and re-test soon. The bummer is, it would be a major impediment to our use of OJB if we couldn't convert on pk fields. We use a custom GUID impl for the pk in many of our BO's and tables. Not sure I fully understand yet the Identity change. Sounds like you are saying internal state was inconsistent? ## I think the made changes are correct, because the conversion was not transparent for the user of the Identity object. I suggest never use converted (java -- sql) pk fields within Identity (I don't know if code base is comply with this suggest, maybe that's the reason for the hassle). The conversion could be done when it's necessary. But nevertheless I think there is a nasty bug when using field conversion with pk fields. - 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]
RE: OJB test failures
Armin, Thank you very much for this! I will build latest and re-test soon. The bummer is, it would be a major impediment to our use of OJB if we couldn't convert on pk fields. We use a custom GUID impl for the pk in many of our BO's and tables. Not sure I fully understand yet the Identity change. Sounds like you are saying internal state was inconsistent? ## I think the made changes are correct, because the conversion was not transparent for the user of the Identity object. I suggest never use converted (java -- sql) pk fields within Identity (I don't know if code base is comply with this suggest, maybe that's the reason for the hassle). The conversion could be done when it's necessary. But nevertheless I think there is a nasty bug when using field conversion with pk fields. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB test failures
Hi again, Not sure I fully understand yet the Identity change. Sounds like you are saying internal state was inconsistent? No, don't misunderstand me I only made presumptions - begin a X-file ;-) I'm not very familiar with this part of OJB source (Jakob, Thomas and Matthew are the specialists for that stuff). regards, Armin - Original Message - From: Andrew Gilbert [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED]; Armin Waibel [EMAIL PROTECTED] Sent: Friday, February 28, 2003 9:43 PM Subject: RE: OJB test failures Armin, Thank you very much for this! I will build latest and re-test soon. The bummer is, it would be a major impediment to our use of OJB if we couldn't convert on pk fields. We use a custom GUID impl for the pk in many of our BO's and tables. Not sure I fully understand yet the Identity change. Sounds like you are saying internal state was inconsistent? ## I think the made changes are correct, because the conversion was not transparent for the user of the Identity object. I suggest never use converted (java -- sql) pk fields within Identity (I don't know if code base is comply with this suggest, maybe that's the reason for the hassle). The conversion could be done when it's necessary. But nevertheless I think there is a nasty bug when using field conversion with pk fields. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OJB test failures
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]
