Is your feature request related to a problem? If so, please give a short summary of the problem and how the feature would resolve it
I use Java 8 time types throughout my code, and would like to avoid using legacy types. This works when using a ResultSet, since it has been updated to support LocalDateTime, etc. (#744), but CallableStatement lacks support for these types.
Describe the preferred solution
I would like to be able to call CallableStatement::getObject(1, LocalDateTime.class) and receive and object, rather than an exception.
Describe alternatives you've considered
I could get a java.sql.Timestamp and use .toLocalDateTime(), but this comes with a performance penalty (#1070), and introduces legacy types into my code.
Additional context
This would require more up-front work, but the code in SQLServerResultSet::getObject(int, Class) is almost identical to SQLServerCallableStatement::getObject(int, Class), and seems eligible for abstraction so that the same types are maintained between CallableStatements and ResultSets, and code duplication is removed. I recognize this difficult (I tried it briefly) since ResultSet and CallableStatement share many methods, but they are not specified by the same interface.
Reference Implementation
SQLServerResultSet
Is your feature request related to a problem? If so, please give a short summary of the problem and how the feature would resolve it
I use Java 8 time types throughout my code, and would like to avoid using legacy types. This works when using a ResultSet, since it has been updated to support LocalDateTime, etc. (#744), but CallableStatement lacks support for these types.
Describe the preferred solution
I would like to be able to call
CallableStatement::getObject(1, LocalDateTime.class)and receive and object, rather than an exception.Describe alternatives you've considered
I could get a
java.sql.Timestampand use.toLocalDateTime(), but this comes with a performance penalty (#1070), and introduces legacy types into my code.Additional context
This would require more up-front work, but the code in
SQLServerResultSet::getObject(int, Class)is almost identical toSQLServerCallableStatement::getObject(int, Class), and seems eligible for abstraction so that the same types are maintained between CallableStatements and ResultSets, and code duplication is removed. I recognize this difficult (I tried it briefly) sinceResultSetandCallableStatementshare many methods, but they are not specified by the same interface.Reference Implementation
SQLServerResultSet