Derby
  1. Derby
  2. DERBY-4615

EmbedCallableStatement ignores Calendar in getDate, getTime and getTimestamp

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.5.3.0
    • Fix Version/s: 10.5.3.1, 10.6.1.0
    • Component/s: JDBC
    • Labels:
      None
    • Issue & fix info:
      Repro attached
    • Bug behavior facts:
      Embedded/Client difference, Wrong query result

      Description

      The getDate(), getTime() and getTimestamp() methods in EmbedCallableStatement ignore the Calendar argument, and therefore give the wrong results if some other calendar than the default calendar is passed in. The client driver seems to do the right thing, though.

      Also note that none of these methods are ever called by any of the regression tests.

      1. ASF.LICENSE.NOT.GRANTED--derby-4615-1a.diff
        10 kB
        Knut Anders Hatlen
      2. ASF.LICENSE.NOT.GRANTED--test.diff
        7 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          Attached is a JUnit test case that exposes the bug. The test case calls a procedure that takes date, time and timestamp values in its input parameters and returns the exact same values through its output parameters. In the test, the getters and setters on the callable statement are called with different combinations of calendars with different time zones, and the test checks whether the correct translation between the time zones has been performed.

          With the client driver, the test passes. With the embedded driver, only the part of the test that uses the local time zone passes.

          Show
          Knut Anders Hatlen added a comment - Attached is a JUnit test case that exposes the bug. The test case calls a procedure that takes date, time and timestamp values in its input parameters and returns the exact same values through its output parameters. In the test, the getters and setters on the callable statement are called with different combinations of calendars with different time zones, and the test checks whether the correct translation between the time zones has been performed. With the client driver, the test passes. With the embedded driver, only the part of the test that uses the local time zone passes.
          Hide
          Knut Anders Hatlen added a comment -

          Currently, the problem is that EmbedCallableStatement defines getXXX(int,Calendar) in terms of getXXX(int), so the Calendar argument is lost. The attached patch turns this situation around. Now all the work is done in the getters that take a Calendar argument, and the Calendar-less getters just forward calls to them after adding the default Calendar instance to the argument list.

          Now the new test case in CallableTest runs cleanly both with the embedded driver and the client driver. I've started a full regression test run.

          Show
          Knut Anders Hatlen added a comment - Currently, the problem is that EmbedCallableStatement defines getXXX(int,Calendar) in terms of getXXX(int), so the Calendar argument is lost. The attached patch turns this situation around. Now all the work is done in the getters that take a Calendar argument, and the Calendar-less getters just forward calls to them after adding the default Calendar instance to the argument list. Now the new test case in CallableTest runs cleanly both with the embedded driver and the client driver. I've started a full regression test run.
          Hide
          Bryan Pendleton added a comment -

          +1 to the suggestion that getXXX(int) should call getXXX(int, Calendar),
          rather than the other way around. Thanks for cleaning this up!

          Show
          Bryan Pendleton added a comment - +1 to the suggestion that getXXX(int) should call getXXX(int, Calendar), rather than the other way around. Thanks for cleaning this up!
          Hide
          Knut Anders Hatlen added a comment -

          Thanks Bryan! All the regression tests passed.
          Committed revision 934474.

          Show
          Knut Anders Hatlen added a comment - Thanks Bryan! All the regression tests passed. Committed revision 934474.
          Hide
          Kathey Marsden added a comment -

          reopen for 10.5 back port

          Show
          Kathey Marsden added a comment - reopen for 10.5 back port
          Hide
          Mamta A. Satoor added a comment -

          I will work on backporting this one

          Show
          Mamta A. Satoor added a comment - I will work on backporting this one
          Hide
          Mamta A. Satoor added a comment -

          The derbyall suite ran fine after the merge. But for junit suite (I ran it twice and both the times, same failure), I get following error. Is this an expected failure and hence we just need to change the test?
          1) testTimeAndDateWithCalendar(org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest)junit.framework.AssertionFailedError: nanos expected:<123456789> but was:<123456000>
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.assertSameTimestamp(CallableTest.java:522)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.testTimeAndDateWithCalendar(CallableTest.java:456)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.testTimeAndDateWithCalendar(CallableTest.java:412)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          Show
          Mamta A. Satoor added a comment - The derbyall suite ran fine after the merge. But for junit suite (I ran it twice and both the times, same failure), I get following error. Is this an expected failure and hence we just need to change the test? 1) testTimeAndDateWithCalendar(org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest)junit.framework.AssertionFailedError: nanos expected:<123456789> but was:<123456000> at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.assertSameTimestamp(CallableTest.java:522) at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.testTimeAndDateWithCalendar(CallableTest.java:456) at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.testTimeAndDateWithCalendar(CallableTest.java:412) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23)
          Hide
          Knut Anders Hatlen added a comment -

          I think this is expected on 10.5 because of DERBY-2602 (not backported).

          Show
          Knut Anders Hatlen added a comment - I think this is expected on 10.5 because of DERBY-2602 (not backported).
          Hide
          Mamta A. Satoor added a comment -

          DERBY-2602 is not in the list of bugs identified for backport to 10.5 but I can look into backporting it so DERBY-4615 does not have the above failure after the merge. Please let me know if any one has any objection to backport of DERBY-2602.

          Show
          Mamta A. Satoor added a comment - DERBY-2602 is not in the list of bugs identified for backport to 10.5 but I can look into backporting it so DERBY-4615 does not have the above failure after the merge. Please let me know if any one has any objection to backport of DERBY-2602 .
          Hide
          Mamta A. Satoor added a comment -

          Can't backport DERBY-2602 into 10.5 because it will change the behavior of client server product when we already have branches on top of the 10.5 codeline. Because of that, I had to change the test to not look for nanosec granularity after the merge of DERBY-4615 into 10.5 codeline. The changes for DERBY-4615 are now in 10.5 codeline

          Show
          Mamta A. Satoor added a comment - Can't backport DERBY-2602 into 10.5 because it will change the behavior of client server product when we already have branches on top of the 10.5 codeline. Because of that, I had to change the test to not look for nanosec granularity after the merge of DERBY-4615 into 10.5 codeline. The changes for DERBY-4615 are now in 10.5 codeline

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development