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