Data type mismatch error for boolean to DECIMAL conversion in J2ME

• Key: DERBY-518
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Deepa Remesh
• Reporter: Deepa Remesh
• Component/s: JDBC
• Fix Version/s: 10.1.2.1, 10.2.1.6

Description

The test jdbcapi/resultset.java gives the following error when run in J2ME/CDC/FP :

Testing nullif(?,DECIMAL(10,5)) with setBoolean
ERROR XCL12: An attempt was made to put a data value of type 'boolean' into a data value of type 'DECIMAL'.

I found that setValue(boolean) is not implemented in BigIntegerDecimal, which is the class used for DECIMAL in J2ME. This is implemented in SQLDecimal and a similar implementation can be provided in BigIntegerDecimal.

On looking at the setValue methods in these classes, I also found that setValue(Object) is implemented in SQLDecimal but not in BigIntegerDecimal.

Comments

[Deepa Remesh]

This patch fixes DERBY-518 and DERBY-453 (Create a test wrapper to run tests using BigDecimal in J2ME/CDC/Foundation). The patch for DERBY-518 can be verified only with the patch for DERBY-453 and viceversa. So I am submitting it as one patch.

Kathey, I have addressed your comments for DERBY-453 in this patch.

Ran derbyall with Sun J2SE 1.4.2 and IBM's WCTME 5.7 J2ME/CDC/FP. 1 failure in J2ME, which is not related to this change.

Please review/commit this patch.

[Kathey Marsden]

Looking at SQLDecimal there are also setValue methods for the other primatives, such as setValue(float) and setValue(int).

Should these be added too?
If so I can go ahead and commit this patch and those can be added later, but I just want to clarify whether all these setValue methods should be there.

[Deepa Remesh]

Thanks Kathey for looking at the patch.

In case of BigIntergerDecimal, the setValue methods for other primitives are implemented in the parent class BinaryDecimal. As I understand, all valid conversions for DECIMAL type specified in the JDBC spec have to be covered.

setValue(Object) should not be implemented in BigIntegerDecimal.

This is because there is no mapping from an Object type to a DECIMAL with JSR169.

[Kathey Marsden]

Oops, sorry I didn't look more closely.

Would it make sense for setValue(boolean) to live in BinaryDecimal as well and not be dependent on BigInteger like setValue(int) and the other setValue(primitive) methods?

[Deepa Remesh]

Thanks Kathey and Dan for your comments.

Kathey, I see the advantage in moving setValue(boolean) to BinaryDecimal and not making it depend on BigInteger - It can be used with all CDC implementations. I'll change this and submit a new patch.

Dan, I will remove setValue(Object) from my patch. I had opened this JIRA issue only for boolean type and I think I should not have overloaded this patch. However, one thing I am not clear about is the data type conversions in JSR169. Is there a table or some section in JSR169 for data type conversions? As it is a subset of JDBC3.0, I have been referring to JDBC3.0 spec and the subset API mentioned in JSR169. My understanding is that objects which are instances of Number or its subclass(other than BigDecimal) can be converted to DECIMAL type in JSR169. I will appreciate any pointers on this.

[Daniel John Debrunner]

Deepa, can you give a section number from JDBC 3.0 indicating any instance of Number can be converted to DECIMAL?

I know SQLDecimal has that code in there (conversion of Number) but I believe it is dead code and cannot/willnot be called.

[Deepa Remesh]

I am referring to "TABLE B-5 Conversions Performed by setObject Between Java Object Types and Target JDBC Types". I change my previous statement to instances of Double,Long, Float,Integer can be converted to DECIMAL. I was also basing on SQLDecimal methods and trying to match as closely as possible. As you mentioned, the code for conversion of Number looks like dead code.

[Daniel John Debrunner]

OK - I see B-5, but that is handled by the setObject() method of PreparedStatement. It does not get through to the setValue(Object) call of SQLDecimal or BigIntegerDecimal.

[Deepa Remesh]

I have deleted my old patch and uploaded the new patch for this. I have moved setValue(boolean) to BinaryDecimal and removed setValue(Object). This patch can be applied to 10.1 branch too.

Ran derbyall with Sun J2SE 1.4.2 and IBM's WCTME 5.7 J2ME/CDC/FP. 1 failure in J2ME, which is not related to this change. The testcase unit/T_RawStoreFactory.unit fails intermittently on J2ME. I will open a JIRA issue for this.

[Deepa Remesh]

I noticed that my patch became invalid because of a commit in between for DERBY-213.

I am submitting a new patch (derby-518_3.diff) with the same set of changes except for the following: The test resultset.java is still excluded from J2ME. It fails because of additions to the test which use a procedure that uses DriverManager. It would be good if this patch can be reviewed/committed. The problem with the test in J2ME can be tracked separately using DERBY-453.

[Deepa Remesh]

Since the comments for this patch are at different places, I am summarising the changes below:

1. Added setValue(boolean) to BinaryDecimal. This fixes DERBY-518.
2. Created a wrapper class BigDecimalHandler to be used in tests.
3. Test jdbcapi/resultset.java modified to call the wrapper methods in BigDecimalHandler
4. resultset.out master files modified
5. Comment in resultsetapp_properties modified. resultset test still fails in J2ME because of additions to the test. This will be tracked in DERBY-453.

Please review/commit this patch.

[Kathey Marsden]

Committed revision 264945 to the trunk.

[Kathey Marsden]

I changed a couple minor things when committing this patch with r264945

1) I updated the canon for the derbynet framework (JCC). Please check the diff.
2) I added the Apache license comment to BigDecimalHandler.

 

[Kathey Marsden]

second checkin for missed file.
Committed revision 265043.

[Kathey Marsden]

Part of the resolution for this issue was checked in with DERBY-518

[Deepa Remesh]

Thanks for looking into the patch. The update to the canon for derbynet is okay.

I will upload another patch for 10.1 branch.

[Deepa Remesh]

I merged the changes for DERBY-518 to 10.1 branch.

264945 : Initial check-in
265043: second check-in
279926: check-in to enable test resultset.java in J2ME

derbyall ran successfully with SUN jdk 1.4.2. The command I used for merge is:

svn merge -r 264944:264945 https://svn.apache.org/repos/asf/db/derby/code/trunk
svn merge -r 265042:265043 https://svn.apache.org/repos/asf/db/derby/code/trunk
svn merge -r 279925:279926 https://svn.apache.org/repos/asf/db/derby/code/trunk

Please update 10.1 branch with this patch.

[Kathey Marsden]

Submitted to the 10.1 branch.

Date: Fri Sep 16 15:25:39 2005
New Revision: 289667

URL: http://svn.apache.org/viewcvs?rev=289667&view=rev

[Deepa Remesh]

Fixed by revisions 264945, 265043, 279926 in trunk and revision 289667 in 10.1 branch

[Deepa Remesh]

reopening to fix fix version