db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed.
Date Tue, 17 Jul 2007 18:07:04 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513309
] 

Mamta A. Satoor commented on DERBY-2896:
----------------------------------------

I spent more time on this problem and following is how I plan to fix it. Any feedback/suggestion
highly appreciated.

EmbedMetaData.getTables is implemented differently than other metadata calls (getUDTs is also
implemented in same manner as getTable but I will talk about getUDTs later). The reason for
different implementation of getTables is "it is altering the metadata query that is stored
in metadata.properties". A user may ask to get specific types of tables when calling getTables.
In that case, EmbedMetaData.getTables adds additional clause to the WHERE clause and that
additional clause is "AND TABLETYPE IN (all the passed table types in getTables)". Because
of this alteration of metadata query, getTables can't look for the saved metadata plan. This
causes the metadata query to be compiled in the current schema rather than in the SYS schema.
For other metadata queries, when we go through SYSSTATEMENTS, we do the work of setting the
current compilation schema as SYS schema and hence those metadata queries do not fail for
collation type mismatch.

To fix getTables problem, I am planning on modifying the metadata query for it to have the
additional clause in it's WHERE clause and the ORDER BY clause (the reason for ORDER BY is
current implementation of getTables adds a ORDER BY in EmbedMetaData.getTables) as follows

AND TABLESTYPE IN (?s for all different types supported by Derby as of today) ORDER BY TABLE_TYPE,
TABLE_SCHEM, TABLE_NAME

EmbedMetaData.getTables will use setString to set the ? to the table types requested by the
user in the metadata call and if there are any unused ?s, they will be set to NULL. Also,
if user has not requested for any specific types, then all the ? will be set to the types
supported by Derby as of today. This approach will not require us to change the metadata query
on the fly in EmbedMetaData.getTables and because of that, we can follow the same path followed
by rest of the metadata call implementations in EmbedMetaData.

As for getUDTs, I think it is a coding error that we do not follow the same logic as rest
of the metadata calls. This is because I don't see us altering the query for getUDTs in EmbedMetaData,getUDTs.
So, I will try to simply have getUDTs have the same code as rest of the other code to see
if it works.

Comments?

> DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState
42818: Comparisions between CHAR and CHAR not allowed.
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2896
>                 URL: https://issues.apache.org/jira/browse/DERBY-2896
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0
>            Reporter: Daniel John Debrunner
>            Assignee: Mamta A. Satoor
>            Priority: Critical
>         Attachments: Test2896.zip
>
>
> I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so that it
would test DatabaseMetaData within a collated database.
> I had to fix one item in JDBC.dropSchema() where a string constant was being compared
to a system column while not in a system schema,
> but with that fixed the next error hit was executing DatabaseMetaData.getTables().
> I will add the code to collation test with the use of DatabaseMetaDataTest commented
out with this bug number.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message