[ http://issues.apache.org/jira/browse/DERBY-137?page=all ]
Knut Anders Hatlen updated DERBY-137:
-------------------------------------
Attachment: derby-137-v2.diff
derby-137-v2.stat
Thank you very much for reviewing, A B!
You are right; NULLABLE, SEARCHABLE, MINIMUM_SCALE and MAXIMUM_SCALE
are still listed as short in the javadoc. I meant to say that they had
been changed from INT to SMALLINT in the queries (which is what the
patch actually did). This means the casts are not necessary for these
columns either in the ODBC queries.
I don't think changing the ODBC rewriting should affect soft upgrade
in any way. Derby will read the new queries directly from
metadata.properties, and they don't require any 10.2 features that are
not available in soft-upgrade mode.
I have attached a new patch (v2) which removes the unnecessary casts
to SMALLINT generated by the ODBC generator. With that change,
getPrimaryKeys() is ODBC compliant, so
SystemProcedures.SQLPRIMARYKEYS() now uses the JDBC query for ODBC
requests.
Derbyall (including the upgrade test) still passes. Do you think these
changes are OK?
> Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result
> sets are required.
> --------------------------------------------------------------------------------------------
>
> Key: DERBY-137
> URL: http://issues.apache.org/jira/browse/DERBY-137
> Project: Derby
> Type: Bug
> Components: JDBC
> Reporter: A B
> Assignee: Knut Anders Hatlen
> Priority: Critical
> Attachments: derby-137-v1.diff, derby-137-v1.stat, derby-137-v2.diff,
> derby-137-v2.stat
>
> BACKGROUND:
> Derby's implementation of the JDBC class java.sql.DatabaseMetaData returns
> result sets that are defined by the SQL queries in
> impl/jdbc/metadata.properties.
> PROBLEM:
> The current queries in the metadata.properties file are for JDBC 2 only. The
> queries do NOT account for the result sets as defined by JDBC 3, and thus
> even when JDBC 3 result sets should be returned, a user will get metadata
> correlating to the JDBC 2 standard.
> Just for reference, here are a couple of examples of changes that have been
> made from JDBC 2 to JDBC 3:
> 1) getColumns(): JDBC 2 specifies 18 columns, JDBC 3 specifies 22 (the four
> extra columns are SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, and
> SOURCE_DATA_TYPE).
> 2) getTables(): JDBC 2 specifics 5 columns, JDBC 3 specifies 10 (the five
> extra columns are TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME,
> and REF_GENERATION).
> 3) getProcedureColumns(): JDBC 2 specifies that DATA_TYPE is a "short"; JDBC
> 3 specifies that DATA_TYPE is an "int".
> NOTES:
> JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to
> just modify metadata.properties to return JDBC 3 result sets...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
