[jira] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
Title: Message Title Rick Hillegas updated an issue Derby / DERBY-6445 JDBC 4.2: Add support for new date and time classes Thanks for the quick feedback, Bryan and Philippe. Attaching rev 2 of the spec, which incorporates your comments. Change By: Rick Hillegas Attachment: Derby-6445.html Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (DERBY-6920) Add input support for new date and time classes
Title: Message Title Philippe Marschall commented on DERBY-6920 Re: Add input support for new date and time classes Yes, I plan to do the rest of the work as well but it may take a moment. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
Title: Message Title Philippe Marschall commented on DERBY-6445 Re: JDBC 4.2: Add support for new date and time classes For the output side of things what is needed is changing the implementation of ResultSet#getObject(int, Class) and ResultSet#getObject(String, Class) so that the types java.time.LocalDate, java.time.LocalTime and java.time.LocalDateTime can be passed as arguments and returned. Unfortunately the specification does not mention this, tables B-4 and B-5 apply only to #setObject and table B-6 does not mention it. So far I can only offer this document from Oracle (at the very end). Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
Title: Message Title Bryan Pendleton commented on DERBY-6445 Re: JDBC 4.2: Add support for new date and time classes I don't see the impact on setNull either, and yet Table B-5 in the spec clearly states that its tabulation of Java Object Types applies to both setObject and setNull. That reference to setNull in the Table B-5 descriptive language confuses me, as setNull only cares about SQL types, not Java Object Types, I think. The JDBC 4.2 spec seems quite clear, in Table B-3, that getObject will never return one of the new Java types; it returns the existing Date, Time, or Timestamp types only. However, the variants of ResultSet.getObject which take a Class instance as an argument might potentially be called with, e.g., java.time.LocalDateTime.class, or even with java.time.OffsetTime.class? In the first case, it seems like we ought to be able to implement this behavior, should we desire to, while in the OffsetTime case, it seems like we ought to perhaps have some sort of "not implemented" behavior? That is, what should we do if we experience: ResultSet rs = ...; LocalDateTime myLocalTimestamp = rs.getObject(3,java.time.LocalDateTime.class); Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (DERBY-6920) Add input support for new date and time classes
Title: Message Title Rick Hillegas commented on DERBY-6920 Re: Add input support for new date and time classes Hi Philippe, I have attached a first draft of a functional spec to derby-6445, describing the work needed for this subtask of that issue. Could you review that spec and add your feedback to the commentary on that issue? In particular, I would be interested to know what output support might be needed. Both you and Knut mentioned that output support might be needed, but I was not able to imagine what it would be. Are you planning to do all of the work described by that functional spec? Thanks, -Rick Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (DERBY-6445) JDBC 4.2: Add support for new date and time classes
Title: Message Title Rick Hillegas updated an issue Derby / DERBY-6445 JDBC 4.2: Add support for new date and time classes Attaching Derby-6445.html, the first rev of a functional spec for this issue. I was able to identify work needed for PreparedStatement/CallableStatement.setObject() methods and for ResultSet.updateObject() methods. Knut mentioned that there might be work needed for getObject() and setNull() methods as well, but I was not able to imagine what that work would entail. Thanks in advance for any feedback which the community may have. Change By: Rick Hillegas Attachment: Derby-6445.html Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)