[ http://issues.apache.org/jira/browse/DERBY-137?page=comments#action_12416518 ]
Knut Anders Hatlen commented on DERBY-137: ------------------------------------------ I have (or more precisely, a test program of mine has) gone through all the DatabaseMetaData methods and compared them to the JDBC 4 spec. This is what I found: 1) Columns are missing from getColumns(), getTables() and getUDTs(). 2) Some columns that the spec says should be "int" are returned as "SMALLINT", and some columns that should be "short" are returned as "INTEGER". What's the best solution for 2? Changing all queries so that short maps to SMALLINT and int to INTEGER? Or should we accept other types as long as they could contain all values of the specified type (that is, allow short to be returned as INTEGER, but not int as SMALLINT)? > 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 > > 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
