You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "A B (JIRA)" <de...@db.apache.org> on 2005/02/02 22:16:19 UTC
[jira] Created: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
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
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Created: (DERBY-137) Derby metadata always returns JDBC
2 result sets, even when JDBC 3 result sets are required.
Posted by Army <ar...@golux.com>.
Mamta Satoor wrote:
>Hi Army,
>
>I could be wrong about this but if we change metadata.properties to return JDBC 3 result sets,
>then won't that be incorrect result sets when running JDBC 2 jdk?
>
>
>"A B (JIRA)" wrote:
>
>
>>> 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...
>>
That was my first thought, too. But then I saw this paragraph in the "Goals" section of the JDBC 3.0 spec:
[ begin quote ]
9. Maintain backward compatibility with existing applications and drivers
Existing JDBC technology-enabled drivers ("JDBC drivers") and the applications that use them must continue to work in an implementation of the Java virtual machine that supports the JDBC 3.0 API. Applications that use only features defined in earlier releases of the JDBC API, excluding those that were deprecated by JDBC 2.0, will not require changes to continue running. It should be straightforward for existing applications to migrate to JDBC 3.0 technology.
[ end quote ]
I also noticed the following little snippet from a web site on JDBC 3.0 (http://www-106.ibm.com/developerworks/java/library/j-jdbcnew/):
[ begin quote ]
Design Goals
The JDBC 3.0 specification is set forth primarily to round out the feature set of prior JDBC specifications. Consequently, one of the guiding design principles of the new specification is to maintain compatibility with existing applications and drivers. Therefore, users of JDBC 2 can expect their applications to function correctly under JDBC 3.0. Additionally, code written to the JDBC 1 API that uses the previously deprecated methods will continue to work.
[ end quote ]
I admit that I didn't investigate these paragraphs any further, so maybe there's more to be learned than what I originally took from them. For example, even if a JDBC 2 application does in fact "function correctly under JDBC 3.0", does that imply that a database which returns JDBC 3.0 metadata is still "JDBC 2 compliant"? I.e. "function correctly" doesn't necessarily equal "JDBC 2 compliant", so maybe you're right--perhaps the fix is more complicated than the NOTE in the JIRA entry suggests...
Any one out there know for sure?
Army
Re: [jira] Created: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by Mamta Satoor <ma...@Remulak.Net>.
Hi Army,
I could be wrong about this but if we change metadata.properties to return JDBC 3 result sets,
then won't that be incorrect result sets when running JDBC 2 jdk?
Mamta
"A B (JIRA)" wrote:
> 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
>
> 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
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ]
Knut Anders Hatlen updated DERBY-137:
-------------------------------------
Attachment: derby-137-v1.diff
derby-137-v1.stat
The attached patch changes the data types and adds missing columns so
that the result sets returned from DatabaseMetaData methods match the
latest revision of the JDBC 4.0 spec. Derbyall ran cleanly on Sun JVM
1.5.0/Solaris 10 x64.
Summary of the changes:
DatabaseMetaData:
- getProcedureColumns: modified VTI to return an int instead of a
short for the DATA_TYPE column
- getTables: new columns: TYPE_CAT, TYPE_SCHEM, TYPE_NAME,
SELF_REFERENCING_COL_NAME, REF_GENERATION (all null since Derby
doesn't support typed tables)
- getColumns: DATA_TYPE changed from SMALLINT to INTEGER. New
columns: SCOPE_CATLOG, SCOPE_SCHEMA, SCOPE_TABLE,
SOURCE_DATATYPE (all null since Derby doesn't support the REF or
DISTINCT data types)
- getVersionColumns: SCOPE, DECIMAL_DIGITS and PSEUDO_COLUMN
changed from INTEGER to SMALLINT
- getPrimaryKeys: KEY_SEQ changed from INTEGER to SMALLINT
- getTypeInfo: DATA_TYPE, NULLABLE, SEARCHABLE, MINIMUM_SCALE and
MAXIMUM_SCALE changed from SMALLINT to INTEGER.
- getIndexInfo: ORDINAL_POSITION changed from INTEGER to SMALLINT
- getBestRowIdentifier: DATA_TYPE changed from SMALLINT to INTEGER
- getUDTs: new columm: BASE_TYPE (null since Derby doesn't support
the DISTINCT type or SELF_REFERENCING_COLUMN)
ODBCMetadataGenerator:
- cast DATA_TYPE columns to SMALLINT (as defined by ODBC)
Tests:
- updated master files for metadata, odbc_metadata,
bestrowidentifier, declareGlobalTempTableJava and
Upgrade_10_1_10_2 (new columns and modified data types)
- odbc_metadata.java: added information about nullability for some
of the new columns to avoid ArrayIndexOutOfBoundsException
> 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
[jira] Updated: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ]
Knut Anders Hatlen updated DERBY-137:
-------------------------------------
Derby Info: [Patch Available]
Patch is available and ready for review. Thanks!
> 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
[jira] Updated: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ]
Rick Hillegas updated DERBY-137:
--------------------------------
Priority: Critical (was: Major)
Bumping the priority of this bug.
> 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
> 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
[jira] Commented: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-137?page=comments#action_12417835 ]
A B commented on DERBY-137:
---------------------------
I hope to review these changes today (06/26 PST) and will post comments as appropriate. Thanks for your patience...
> 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
[jira] Commented: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Updated: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Closed: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ]
A B closed DERBY-137:
---------------------
Fix contributed and committed by Knut, so I'm closing the issue.
> 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
> Fix For: 10.2.0.0
> 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
[jira] Assigned: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ]
Knut Anders Hatlen reassigned DERBY-137:
----------------------------------------
Assign To: Knut Anders Hatlen
> 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
[jira] Resolved: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ]
Knut Anders Hatlen resolved DERBY-137:
--------------------------------------
Fix Version: 10.2.0.0
Resolution: Fixed
Derby Info: (was: [Patch Available])
Thanks again for the quick review, A B! Committed v2 patch into trunk with revision 417497.
> 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
> Fix For: 10.2.0.0
> 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
[jira] Commented: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-137?page=comments#action_12418050 ]
A B commented on DERBY-137:
---------------------------
> Derbyall (including the upgrade test) still passes. Do you think these changes are OK?
Yes, the latest patch looks good to me. Thanks much for addressing my comments.
+1 to commit.
> 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
[jira] Commented: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ 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!
> 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
[jira] Commented: (DERBY-137) Derby metadata always returns JDBC 2
result sets, even when JDBC 3 result sets are required.
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ 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