[
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<T>)}} logs
method entry, but does not log method exit. It ends up calling
{{org.apache.derby.client.am.ClientResultSet#getObject(int, Class<T>)}} 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)
