Derby
  1. Derby
  2. DERBY-518

Data type mismatch error for boolean to DECIMAL conversion in J2ME

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.1.2.1, 10.2.1.6
    • Component/s: JDBC
    • Labels:
      None
    • Environment:
      J2ME/CDC/Foundation Profile

      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.

      1. derby-518_3.diff
        13 kB
        Deepa Remesh
      2. ASF.LICENSE.NOT.GRANTED--derby-518_2.status
        0.5 kB
        Deepa Remesh
      3. ASF.LICENSE.NOT.GRANTED--derby-518_2.diff
        13 kB
        Deepa Remesh

        Issue Links

          Activity

          Hide
          Deepa Remesh added a comment -

          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.

          Show
          Deepa Remesh added a comment - 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.
          Hide
          Kathey Marsden added a comment -

          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.

          Show
          Kathey Marsden added a comment - 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.
          Hide
          Deepa Remesh added a comment -

          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.

          Show
          Deepa Remesh added a comment - 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.
          Hide
          Daniel John Debrunner added a comment -

          setValue(Object) should not be implemented in BigIntegerDecimal.

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

          Show
          Daniel John Debrunner added a comment - setValue(Object) should not be implemented in BigIntegerDecimal. This is because there is no mapping from an Object type to a DECIMAL with JSR169.
          Hide
          Kathey Marsden added a comment -

          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?

          Show
          Kathey Marsden added a comment - 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?
          Hide
          Deepa Remesh added a comment -

          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.

          Show
          Deepa Remesh added a comment - 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.
          Hide
          Daniel John Debrunner added a comment -

          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.

          Show
          Daniel John Debrunner added a comment - 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.
          Hide
          Deepa Remesh added a comment -

          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.

          Show
          Deepa Remesh added a comment - 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.
          Hide
          Daniel John Debrunner added a comment -

          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.

          Show
          Daniel John Debrunner added a comment - 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.
          Hide
          Deepa Remesh added a comment -

          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.

          Show
          Deepa Remesh added a comment - 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.
          Hide
          Deepa Remesh added a comment -

          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.

          Show
          Deepa Remesh added a comment - 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 .
          Hide
          Deepa Remesh added a comment -

          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.

          Show
          Deepa Remesh added a comment - 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.
          Hide
          Kathey Marsden added a comment -

          Committed revision 264945 to the trunk.

          Show
          Kathey Marsden added a comment - Committed revision 264945 to the trunk.
          Hide
          Kathey Marsden added a comment -

          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.

          Show
          Kathey Marsden added a comment - 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.
          Hide
          Kathey Marsden added a comment -

          second checkin for missed file.
          Committed revision 265043.

          Show
          Kathey Marsden added a comment - second checkin for missed file. Committed revision 265043.
          Hide
          Kathey Marsden added a comment -

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

          Show
          Kathey Marsden added a comment - Part of the resolution for this issue was checked in with DERBY-518
          Hide
          Deepa Remesh added a comment -

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

          I will upload another patch for 10.1 branch.

          Show
          Deepa Remesh added a comment - Thanks for looking into the patch. The update to the canon for derbynet is okay. I will upload another patch for 10.1 branch.
          Hide
          Deepa Remesh added a comment -

          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.

          Show
          Deepa Remesh added a comment - 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.
          Hide
          Kathey Marsden added a comment -

          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

          Show
          Kathey Marsden added a comment - 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
          Hide
          Deepa Remesh added a comment -

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

          Show
          Deepa Remesh added a comment - Fixed by revisions 264945, 265043, 279926 in trunk and revision 289667 in 10.1 branch
          Hide
          Deepa Remesh added a comment -

          reopening to fix fix version

          Show
          Deepa Remesh added a comment - reopening to fix fix version

            People

            • Assignee:
              Deepa Remesh
              Reporter:
              Deepa Remesh
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development