db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
Date Fri, 18 Nov 2011 14:34:52 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas updated DERBY-5488:
---------------------------------

    Attachment: derby-5488-10-aa-metadataTypo.diff

Attaching derby-5488-10-aa-metadataTypo.diff. This a simple candidate patch to change SCOPE_CATLOG
to SCOPE_CATALOG. Regression tests pass cleanly on this patch.

Before discussing this patch and alternatives we might consider, I want to summarize my understanding
of this problem:

A) The JDBC expert group regards this as fixing a typo in the javadoc. I believe that some
other databases recognized the typo for what it was and always named the column SCOPE_CATALOG.
Derby, however, hewed closely to the published javadoc and called the column SCOPE_CATLOG.

B) For those other databases, there is no functional change. A documentation typo has simply
been corrected. For Derby, however, the change creates a backward incompatibility.

C) Derby must break one of its important constraints. There is no way that we can conform
to the corrected JDBC javadoc and avoid a backward incompatibility.

D) I think that the backward incompatibility is quite minor, nevertheless. The column in question
carries no meaning for Derby. The column only has meaning for databases which implement both
catalogs and reference types. For Derby, the column always contains a null. I doubt that (m)any
Derby users inspect this column at all, let alone by name.

Here are the user-visible effects of some possible solutions:

1) Based on engine version - The column is called SCOPE_CATALOG if  DatabaseMetaData.getDatabaseMajorVersion()
and DatabaseMetaData.getDatabaseMinorVersion() report that the engine is at Derby 10.9 or
higher. Otherwise, the column is called SCOPE_CATLOG. This is the approach taken by this patch.

2) Based on client version - The column is called SCOPE_CATALOG if  DatabaseMetaData.getDriverMajorVersion()
and DatabaseMetaData.getDriverMinorVersion() report that the client is at Derby 10.9 or higher.
Otherwise, the column is called SCOPE_CATLOG.

3) Based on JDBC driver version - The column is called SCOPE_CATALOG if DatabaseMetaData.getJDBCMajorVersion()
and DatabaseMetaData.getJDBCMinorVersion() report that the driver is at JDBC 4.1 or higher.
Otherwise, the column is called SCOPE_CATLOG.

Even fancier solutions are possible. They involve combinations of the JDBC and driver versions
at the client and engine. I believe that the solutions listed above give rise to straightforward
workarounds for applications affected by this change. They are easy to explain. The fancier
solutions push more complexity into the application and/or involve backporting tricky code
into older Derby branches.

Of the straightforward solutions, I opted for (1) because it was the easiest to implement.
A casual look at options (2) and (3) suggests that they involve adding some potentially tricky
code to our JDBC drivers. I did not think that this problem warranted the additional complexity.

But those are my opinions. I am open to arguments that we should solve this problem a different
way.

Thanks in advance for your feedback.

Touches the following files:

------------

M       java/engine/org/apache/derby/impl/jdbc/metadata.properties
M       java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java

Actual change to the JDBC metadata.

------------

M       java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java

Corresponding change to the regression test for this metadata.

                
> Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
> -----------------------------------------------------------------------
>
>                 Key: DERBY-5488
>                 URL: https://issues.apache.org/jira/browse/DERBY-5488
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, SQL
>    Affects Versions: 10.9.0.0
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff,
derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff,
derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff,
derby-5488-07-aa-booleanObjects.diff, derby-5488-08-aa-extraLimitOffsetTest.diff, derby-5488-09-aa-jdbcMinorVersion.diff,
derby-5488-10-aa-metadataTypo.diff, z.java
>
>
> In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other
items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the
JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html.
I will attach a functional spec for the remaining bits.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message