[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853797#comment-17853797 ] Richard N. Hillegas commented on DERBY-6445: Linking this issue to DERBY-6834, another discussion about the precision of Derby's DATE/TIME/TIMESTAMP types. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, > derby-6445-02-aa-patchExplanation.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853796#comment-17853796 ] Richard N. Hillegas commented on DERBY-6445: Thanks for your thoughts, Philippe and Bryan. It seems that there is broad agreement that the precision of Derby's TIME datatype is outside the scope of this JIRA issue. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, > derby-6445-02-aa-patchExplanation.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853720#comment-17853720 ] Bryan Pendleton commented on DERBY-6445: I think your reasoning is quite compelling, thank you for sharing that thought process. I wonder, though: could we perhaps consider that a *different* enhancement, as it seems somewhat independent of this work? That is, perhaps we can declare this work finished and track the sub-second behavior of TIME under a separate Jira work item? > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, > derby-6445-02-aa-patchExplanation.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853703#comment-17853703 ] Philippe Marschall commented on DERBY-6445: --- I think there are two different questions: # Should the code for this JIRA silently truncate {{LocalTime}} to seconds? I believe so based on the current behavior of {{java.sql.Time}}. I just wanted to bring it up as it may not be immediately obvious. # Should {{TIME}} in Apache Derby support sub-second precision? If not should it silently truncate? This is a much boarder question that I believe goes beyond the scope of this JIRA. Unfortunately I do not have access to the SQL standard. I would like make two arguments for {{TIME}} supporting sub-second resolution. The first is a conceptual one, if a {{TIMESTAMP}} is an aggregate of a {{DATE}} and a {{TIME}} and {{TIMESTAMP}} has a sub-second resolution doesn't that mean that {{TIME}} should also have a sub-second resolution? Second a lot of other RDBMS support sub-second resolution for {{TIME}} * PosgreS https://www.postgresql.org/docs/current/datatype-datetime.html * SQL Server https://learn.microsoft.com/en-us/sql/t-sql/data-types/time-transact-sql * MySQL https://dev.mysql.com/doc/refman/8.4/en/fractional-seconds.html * H2 http://www.h2database.com/html/datatypes.html#time_type * HSQLDB https://www.hsqldb.org/doc/guide/sqlgeneral-chapt.html#sgc_datetime_types Oracle does not have a {{TIME}} datatype and DB2 does not support sub-second resolution https://www.ibm.com/docs/en/db2-for-zos/13?topic=values-time https://www.ibm.com/docs/en/db2/11.5?topic=list-datetime-values As for Derby itself {{org.apache.derby.iapi.types.SQLTime}} already has a {{#encodedTimeFraction}} that is currently always 0 as {{#computeEncodedTime}} does not read the milliseconds from the calendar. The Derby client itself seems to support sub-second resolution for {{Time}} if I have a look at {{org.apache.derby.client.am.CrossConverters#setObject(int, Timestamp)}} or {{DateTimeValue#DateTimeValue(Time, Calendar)}}. Whether {{java.sql.Time}} supports sub-second resolution or truncates to seconds is a bit more complicated. Unfortunately the class comment is not very clear. What speaks for the truncation is that both {{#toString()}} and {{#valueOf(LocalTime)}} both truncate to seconds. What speaks against it is that it is possible to get the milliseconds out again. If we create a {{Calendar}} from the {{Time}} we get the millisecond value. {{code}} Calendar creationCalendar = Calendar.getInstance(); creationCalendar.clear(); creationCalendar.set(Calendar.YEAR, 1970); creationCalendar.set(Calendar.MONTH, Calendar.JANUARY); creationCalendar.set(Calendar.DAY_OF_MONTH, 1); creationCalendar.set(Calendar.HOUR_OF_DAY, 1); creationCalendar.set(Calendar.MINUTE, 2); creationCalendar.set(Calendar.SECOND, 3); int millis = 456; creationCalendar.set(Calendar.MILLISECOND, millis); Time time = new Time(creationCalendar.getTimeInMillis()); Calendar readBack = Calendar.getInstance(); readBack.setTimeInMillis(time.getTime()); assertEquals(millis, readBack.get(Calendar.MILLISECOND)); {{code}} However when going through Derby it is always truncated to seconds. I haven't debugged it but would assume because {{org.apache.derby.iapi.types.SQLTime#encodedTimeFraction}} is always 0. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, > derby-6445-02-aa-patchExplanation.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851796#comment-17851796 ] Richard N. Hillegas commented on DERBY-6445: Thanks for that great explanation, Philippe. I have added it to the header comment of SQLTimstamp. I am confused about the subtleties surrounding the precision of the java.sql.Time and SQL TIME types. My experiments show that java.sql.Time truncates a millisecond-granularity timestamp to seconds, throwing away the excess milliseconds, even using the Calendar code you included. The SQL TIME datatype has HOUR, MINUTE, and SECONDs parts (no milliseconds), according to the SQL Standard, part 2 (Foundation), clause 4.6.2 (Datetimes). So it seems to me that the code in the patch is correct as is. Here is the experiment I ran: {noformat} import java.sql.*; import java.util.Calendar; public class TimeTest { public static void main(String... args) throws Exception { Connection conn = DriverManager.getConnection("jdbc:derby:memory:db;create=true"); prepareStatement(conn, "CREATE TABLE t(a TIME)").execute(); Time time1 = new Time(System.currentTimeMillis()); Calendar calendar = Calendar.getInstance(); calendar.clear(); calendar.set(Calendar.YEAR, 1970); calendar.set(Calendar.MONTH, Calendar.JANUARY); calendar.set(Calendar.DAY_OF_MONTH, 1); calendar.set(Calendar.HOUR_OF_DAY, 1); calendar.set(Calendar.MINUTE, 2); calendar.set(Calendar.SECOND, 3); calendar.set(Calendar.MILLISECOND, 456); Time time2 = new Time(calendar.getTimeInMillis()); try (PreparedStatement ps = prepareStatement(conn, "INSERT INTO t VALUES (?)")) { setTime(ps, time1); ps.execute(); setTime(ps, time2); ps.execute(); } try (PreparedStatement ps = prepareStatement(conn, "SELECT * from t")) { try (ResultSet rs = ps.executeQuery()) { while(rs.next()) { println(rs.getTime(1).toString()); } } } } private static void setTime(PreparedStatement ps, Time time) throws SQLException { println("Setting time column to " + time.toString()); ps.setTime(1, time); } private static PreparedStatement prepareStatement(Connection conn, String text) throws SQLException { println("Preparing '" + text + "' ..."); return conn.prepareStatement(text); } private static void println(String text) { System.out.println(text); } } {noformat} Here is the output of that experiment: {noformat} Preparing 'CREATE TABLE t(a TIME)' ... Preparing 'INSERT INTO t VALUES (?)' ... Setting time column to 12:26:04 Setting time column to 01:02:03 Preparing 'SELECT * from t' ... 12:26:04 01:02:03 {noformat} > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, > derby-6445-02-aa-patchExplanation.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851770#comment-17851770 ] ASF subversion and git services commented on DERBY-6445: Commit 1918137 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1918137 ] DERBY-6445: Add the explanation by Philippe to the header comment of SQLTimestamp; commit derby-6445-02-aa-patchExplanation.diff. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, > derby-6445-02-aa-patchExplanation.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851769#comment-17851769 ] Richard N. Hillegas commented on DERBY-6445: Attaching derby-6445-02-aa-patchExplanation.diff. This patch adds Philippe's explanation to the header comment for SQLTimestamp. Touches the following files: {noformat} M java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLTimestamp.java Philippe's explanation. M java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLDate.java M java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLTime.java References to the SQLTimestamp header comment, for people interested in following the behavior of java.time.LocalDate and java.time.LocalTime. {noformat} > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, > derby-6445-02-aa-patchExplanation.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851754#comment-17851754 ] ASF subversion and git services commented on DERBY-6445: Commit 1918136 from Richard N. Hillegas in branch 'code/branches/10.15' [ https://svn.apache.org/r1918136 ] DERBY-6445: Port 1918123 from trunk to 10.15 branch. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851751#comment-17851751 ] ASF subversion and git services commented on DERBY-6445: Commit 1918135 from Richard N. Hillegas in branch 'code/branches/10.16' [ https://svn.apache.org/r1918135 ] DERBY-6445: Port 1918123 from trunk to 10.16 branch. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851750#comment-17851750 ] ASF subversion and git services commented on DERBY-6445: Commit 1918134 from Richard N. Hillegas in branch 'code/branches/10.17' [ https://svn.apache.org/r1918134 ] DERBY-6445: Port 1918123 from trunk to 10.17 branch. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851457#comment-17851457 ] Philippe Marschall commented on DERBY-6445: --- I'm probably the worst person to search potential of issues in my code. Nevertheless here are some potential issues to consider: The {{LocalTime}}, {{LocalDate}} and {{LocalDateTime}} abstractions are [very simple| https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/time/package-summary.html] and match very well to SQL types {{DATE}}, {{TIME}} and {{TIMESTAMP}}. This is by design. {quote} LocalDate stores a date without a time. This stores a date like '2010-12-03' and could be used to store a birthday. LocalTime stores a time without a date. This stores a time like '11:30' and could be used to store an opening or closing time. LocalDateTime stores a date and time. This stores a date-time like '2010-12-03T11:30'. {quote} Notice there is no reference to time zones, epochmillis and what not. This is reflected in the code, nowhere except for `#updateObject` does the new code mess with `Calendar`. This the first way using the {{java.time}} classes can result in different results than using the {{java.sql}} classes. As there is no reference to a time zone there are also no time zone artifacts in the behavior. For example you can not store a {{Timestamp}} of {{2025-03-30 02:30}} in Derby if you're using the default {{Calendar}} and your JVM time zone is Europe/Berlin. This is because it falls into a DST transition, on {{2025-03-30 02:00}} the clocks are forwarded to {{2025-03-30 03:00}} hence {{2025-03-30 02:30}} "doesn't exist" in the JVM default time zone used by {{Timestap}}. Storing a {{LocalDateTime}} of {{2025-03-30 02:30}} on the other hand will work independent of the JVM default time zone as we bypass {{Calendar}} and therefore time zones. Writing tests for this would either require calling {{TimeZone.setDefault}} or relying on the test being run in a time zone that has daylight savings time. The second difference is that the {{java.time}} classes use a [proleptic calendar|https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar] meaning our current leap year rules are applied "forever" and there is no jump from 4 October 1582 to 15 October 1582. This is called an ISO calendar and my understanding is what the [SQL standard intends|https://www.postgresql.org/docs/current/datetime-units-history.html]. To give you an example {code} DAY(TIMESTAMP('1582-10-10 10:11:12.12345678')) {code} will return 20 with Derby, not 10. Using {{java.time}} classes will not fix this but will allow storing and retrieving of {{1582-10-10 10:11:12.12345678}}. Some tests here may also make sense. The {{java.time}} classes default to ISO formatting meaning they use {{'T'}} instead of {{' '}} as a separator between day and time hence the need for a custom {{DateTimeFormatter}}. The implementation as in the patch silently truncates {{LocalTime}} to seconds. {{LocalTime}} supports sub second resolution but the code in the patch ignores it. This is similar to the behavior of {{java.sql.Time}}. We can create a {{java.sql.Time}} with sub second resolution like so {{code}} Calendar calendar = Calendar.getInstance(); calendar.clear(); calendar.set(Calendar.YEAR, 1970); calendar.set(Calendar.MONTH, Calendar.JANUARY); calendar.set(Calendar.DAY_OF_MONTH, 1); calendar.set(Calendar.HOUR_OF_DAY, 1); calendar.set(Calendar.MINUTE, 2); calendar.set(Calendar.SECOND, 3); calendar.set(Calendar.MILLISECOND, 456); new Time(calendar.getTimeInMillis())); {{code}} If there's agreement on the intended behavior then some tests here may also make sense. And finally the {{java.time}} types operate on the [Java Time-Scale|https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/time/Instant.html] meaning they no not observe leap seconds. It is my understanding {{java.sql}} types do [not|https://bugs.openjdk.org/browse/JDK-4272347] support leap seconds either. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedSt
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851443#comment-17851443 ] ASF subversion and git services commented on DERBY-6445: Commit 1918123 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1918123 ] DERBY-6445: Add JDBC support for new Time types; commit derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, the patch contributed by Philippe Marschall. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849588#comment-17849588 ] Richard N. Hillegas commented on DERBY-6445: Attaching derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff. This adds some additional tweaks to the derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff patch. Also attaching tweaks.diff which shows the difference between derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff and derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff. The tweaks are: 1) Diagnostic traces were added for entering and exiting some of the methods. As Philippe points out, there is no ideal approach to this problem. The original tracing was for entering/exiting the JDBC getter and setter methods. This breaks down when dealing with get/setObject() because those methods forward to more specific getters and setters. I added traces to the new forwarding methods. 2) I reduced the visibility of some of the new methods from public to private in order to avoid encroaching on public interfaces which may change in future revs of the JDBC spec. 3) I changed the data types reported in some error messages. This patch touches the same files as the previous patches. I ran full tests using both the classpath and the modulepath. Both runs were clean. I am inclined to commit this patch because, despite my reservations (see below), I think that this is a large piece of solid, incremental work. Having some support for these data types is better than raising exceptions. Thanks, Philippe, for this valuable contribution. My chief reservations are the following: A) I am not an expert on the new date/time classes. I can't evaluate whether the patch causes these types to serialize and deserialize correctly. These classes came out of long, tortured discussions among Java champions and my sense is that the experts failed to reach consensus. I have nothing to add to those discussions. I am worried that an expert may log a bug saying that Derby is not (de)serializing these classes correctly. B) Therefore, I would like to see some comments which explain the approach taken in serializing these objects, that is, for converting between the new classes and the JDBC types which Derby already supports. Right now, there are very few comments in this large patch. The comments should help us field bug reports which may be filed against the correctness of the serialization. C) I would also like to see comments added to the new test methods, explaining what the methods are testing. Thanks, -Rick > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, > derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849434#comment-17849434 ] Philippe Marschall commented on DERBY-6445: --- Thank you. Looking forward to it. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849411#comment-17849411 ] Richard N. Hillegas commented on DERBY-6445: Thanks for your thoughts about diagnostic logging, Philippe. I am going through the patch, making additional tweaks, including adding diagnostic logging calls. We can discuss this further when I post that revised patch. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849373#comment-17849373 ] Philippe Marschall commented on DERBY-6445: --- About the diagnostic logging, it is not clear to me how this could best be implemented. To give you an example: {{org.apache.derby.client.am.ClientResultSet#getObject(String, Class)}} logs method entry, but does not log method exit. It ends up calling {{org.apache.derby.client.am.ClientResultSet#getObject(int, Class)}} which also logs method entry and not log method exit as well. This can end up calling an existing method like {{org.apache.derby.client.am.ClientResultSet#getDate(int, Calendar)}} which logs method entry and method exit or a new method like {{org.apache.derby.impl.jdbc.EmbedResultSet#getLocalDate(int)}} which, as you pointed out correctly, does not do any diagnostic logging. My reasoning here is this is a {{private}} utility method that can only be called indirectly while {{#getDate}} is a {{public}} API method that can be called directly by client code. Diagnostic logging currently only seems be done for {{public}} methods and very few {{protected}} methods these being four {{finalize}} methods and two methods on {{BasicClientDataSource}}. The situation is similar for {{org.apache.derby.client.am.ClientPreparedStatement}} and {{#setObject}}. I see several options and would welcome your guidance: - I could add diagnostic logging directly to the new {{private}} methods, they would become the first {{private}} methods to have diagnostic logging. - Inline the new {{private}} methods into {{ClientResultSet}}. Not ideal. - I could extend the diagnostic logging of {{#getObject}} to also log method exit. That would still result in different diagnostic logs depending on whether {{#getObject}} is called with {{java.sql.Date}} ({{#getObject}} and {{#getDate}} are logged) or with {{java.time.LocalTime}} (only {{#getObject}} is logged). To avoid this they would have to be split into a {{public}} method which performs diagnostic logging and a {{private}} one which contains the rest of the implementation. {{#getObject}} would call the latter to avoid logging twice. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849372#comment-17849372 ] Richard N. Hillegas commented on DERBY-6445: Tests passed (with the classpath) on derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849350#comment-17849350 ] Richard N. Hillegas commented on DERBY-6445: Attaching derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff. This is Philippe's patch plus some fixes for its Javadoc warnings. I will run full tests against this patch. A quick glance at the patch indicates that some methods are missing the diagnostic logging which appears in sister methods. At a minimum, the patch will need a little more tweaking to bring it into alignment with that diagnostic logging pattern. Touches the following files: {noformat} M java/org.apache.derby.client/org/apache/derby/client/am/ClientCallableStatement.java M java/org.apache.derby.client/org/apache/derby/client/am/ClientPreparedStatement.java M java/org.apache.derby.client/org/apache/derby/client/am/ClientResultSet.java M java/org.apache.derby.client/org/apache/derby/client/am/CrossConverters.java M java/org.apache.derby.client/org/apache/derby/client/am/Cursor.java M java/org.apache.derby.client/org/apache/derby/client/am/DateTime.java M java/org.apache.derby.client/org/apache/derby/client/am/DateTimeValue.java M java/org.apache.derby.engine/org/apache/derby/iapi/types/DataType.java M java/org.apache.derby.engine/org/apache/derby/iapi/types/DataValueDescriptor.java M java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLChar.java M java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLClob.java M java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLDate.java M java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLTime.java M java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLTimestamp.java M java/org.apache.derby.engine/org/apache/derby/iapi/types/UserType.java M java/org.apache.derby.engine/org/apache/derby/impl/jdbc/EmbedCallableStatement.java M java/org.apache.derby.engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement.java M java/org.apache.derby.engine/org/apache/derby/impl/jdbc/EmbedResultSet.java M java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/CallableStatementTest.java M java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/PreparedStatementTest42.java M java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/Wrapper41Test.java {noformat} > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, > derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849349#comment-17849349 ] Richard N. Hillegas commented on DERBY-6445: Thanks, Philippe. I will take a look at this patch. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849273#comment-17849273 ] Philippe Marschall commented on DERBY-6445: --- I attached a patch. It contains: - Support for both embedded and client mode. - Support for both {{ResultSet}} and {{CallableStatement}}. - Support for {{#getObject}}, {{#setObject}} and {{#updateObject}}. The code avoids converting through {{java.sql}} types or {{Calendar}} and instead uses {{java.time}} types directly. Care has been taken to not affect existing code paths. Limitations: - {{#updateObject}} goes through the {{java.sql}} types, meaning to introduces the limitations of the {{java.sql}} times. I assume the method is used rarely enough so that this is acceptable. If not storing {{DateTimeValue}} instead of {{java.sql}} types in {{ClientResultSet.updatedColumns_}} would be an option. - Java stored procedure implementations do not yet support java.time parameters. This would be more involved as method lookup would have to be updated and input/output conversion would have to happen. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen >Priority: Major > Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
[ https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848534#comment-15848534 ] Knut Anders Hatlen commented on DERBY-6445: --- I cannot recall what I said about setNull(), and I don't think anything is needed there. As to getObject(), even if this conversion is only mentioned in the conversion tables for setObject(), [the spec for getObject()|http://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#getObject-int-java.lang.Class-] says: "At a minimum, an implementation must support the conversions defined in Appendix B, Table B-3 and conversion of appropriate user defined SQL types to a Java type which implements SQLData, or Struct. Additional conversions may be supported and are vendor defined." So it sounds like we're free to add more conversions, and I think these ones make sense. > JDBC 4.2: Add support for new date and time classes > --- > > Key: DERBY-6445 > URL: https://issues.apache.org/jira/browse/DERBY-6445 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.10.1.1 >Reporter: Knut Anders Hatlen > Attachments: Derby-6445.html, Derby-6445.html > > > JDBC 4.2 added type mappings for new date and time classes found in Java 8. > Derby should support these new mappings. > This would at least affect Derby's implementation of the various getObject(), > setObject() and setNull() methods in ResultSet, PreparedStatement and > CallableStatement. -- This message was sent by Atlassian JIRA (v6.3.15#6346)