[
https://issues.apache.org/jira/browse/DERBY-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754678#comment-13754678
]
Rick Hillegas commented on DERBY-6324:
--------------------------------------
Thanks for picking up this issue, Myrna. Getting this information out of
JVMInfo sounds like a good idea to me. The logic which compares strings in the
DatabaseMetaData implementations might be a little brittle. I would suggest
adding a couple more static methods to JVMInfo. These methods could be called
by the DatabaseMetaData implementations:
public static int jdbcMajorVersion() { return 4; }
public static int jdbcMinorVersion()
{
switch ( JDK_ID )
{
case J2SE_16: return 0;
case J2SE_17: return 1;
case J2SE_18:
default:
return 2;
}
}
For extra credit, these methods could be used to construct the version strings
in JVMInfo.derbyVMLevel(). That way the JDBC level would still be maintained in
only one place.
Thanks,
-Rick
> DatabaseMetaData.getJDBCMinorVersion() should return 2 now that we've
> implemented JDBC 4.2
> ------------------------------------------------------------------------------------------
>
> Key: DERBY-6324
> URL: https://issues.apache.org/jira/browse/DERBY-6324
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.10.1.1
> Reporter: Rick Hillegas
> Assignee: Myrna van Lunteren
> Attachments: DERBY-6324.diff
>
>
> Now that the work on DERBY-6000 is done,
> DatabaseMetaData.getJDBCMinorVersion() should return 2 rather than 1. The
> following script shows that we're still returning 1:
> connect 'jdbc:derby:memory:db;create=true';
> call syscs_util.syscs_register_tool( 'databaseMetaData', true );
> values getJDBCMajorVersion();
> values getJDBCMinorVersion();
> call syscs_util.syscs_register_tool( 'databaseMetaData', false );
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira