db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
Date Mon, 26 Jun 2006 17:57:33 GMT
    [ http://issues.apache.org/jira/browse/DERBY-137?page=comments#action_12417860 ] 

A B commented on DERBY-137:
---------------------------

Knut Anders Hatlen (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DERBY-137?page=comments#action_12417738 ]

> 
> Knut Anders Hatlen commented on DERBY-137:
> ------------------------------------------
> 
> I plan to commit this patch tomorrow. If someone is planning to review, 
> please let me know and I'll hold the commit. Thanks!

Changes look good to me.  Thanks for outlining the changes in the above comment, and for taking
care to preserve ODBC metadata compatibility.

I have two very minor comments/questions, but I don't think either is important enough to
block the commit of this patch; I'm just wondering a couple of things...

First:

> - getVersionColumns: SCOPE, DECIMAL_DIGITS and PSEUDO_COLUMN
>      changed from INTEGER to SMALLINT 
>
> - getPrimaryKeys: KEY_SEQ changed from INTEGER to SMALLINT 
>
> - getIndexInfo: ORDINAL_POSITION changed from INTEGER to SMALLINT 

Are the casts to SMALLINT in ODBCMetadataGenerator for these columns still necessary, then?
 I'm not saying you have to remove the casts, but doing so would (slightly) simplify the ODBC-generated
queries.  On the other hand, maybe it's safer to leave the casts in place--could perhaps play
a role in soft-upgrade...?  I haven't looked at this very closely, but since it's not wrong
to leave the casts in, and since there may be cases (w.r.t upgrade) where it's useful, I guess
it's fine to leave the casts in.  Just thought I'd mention it, though, "for the record"...
:)

 - getTypeInfo: DATA_TYPE, NULLABLE, SEARCHABLE, MINIMUM_SCALE and
      MAXIMUM_SCALE changed from SMALLINT to INTEGER. 

When I look at the SE v1.4.2 document, NULLABLE, SEARCHABLE, MINIMUM_SCALE and MAXIMUM_SCALE
are still listed as "short" instead of "integer".

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/DatabaseMetaData.html#getTypeInfo()

In your comment you noted that your changes are in accordance with the "latest revision of
the JDBC 4.0 spec"--i.e. not JDBC 3, which is what the "Summary" field of this Jira issue
says.  But theoretically JDBC 4 should be backward compatible with JDBC 3, so I guess this
is okay...?

But that said, I also noticed that the JDK 6 API (SE 6 b89 API) lists "short" instead of "integer",
as well:

http://download.java.net/jdk6/doc/api/java/sql/DatabaseMetaData.html#getTypeInfo()

I'm assuming that's just because those pages haven't been updated to reflect the latest JDBC
4 spec...?

But again, these are minor nits--just looking for some clarification.  The changes look good
to me and the master updates look to be complete.  Thanks again for being thorough, esp. w.r.t
to ODBC.


> 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
>
> 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


Mime
View raw message