Derby
  1. Derby
  2. DERBY-2896

DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 10.3.1.4, 10.4.1.3
    • Fix Version/s: 10.3.1.4, 10.4.1.3
    • Component/s: JDBC
    • Labels:
      None

      Description

      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.

      1. Test2896.zip
        176 kB
        Stan Bradbury

        Issue Links

          Activity

          Hide
          Stan Bradbury added a comment -

          Performed a basic test on a database (toursdb) created with territory=territory=es_MX - a simple progam that lists tables, exported keys and columns works fine (DbMD.getTables then getExportedKeys then getColumns). This could be a test issue or under a specific configuration. Since basic functionality is not impaired I think the priority of this issue can be lowered. Attached is a zipfile with the simple test program and toursDB created with es_MX territory for any one who might find this helpful.

          Db build:
          ij> connect 'jdbc:derby:work\dbs\toursMx;create=true;territory=es_MX';
          ij> run 'ToursDB_schema.sql';
          ij> run 'loadCOUNTRIES.sql';
          ij> exit;

          %% java DBMetaData2
          Loaded the derby JDBC driver.
          Get Tables Results Loop
          Got a TABLE named: AIRLINES
          . . Getting Exported Keys
          . . . Getting Columns
          . . . . Col: AIRLINE - Type: 1 Size: 2
          . . . . Col: AIRLINE_FULL - Type: 12 Size: 24
          . . . . Col: BASIC_RATE - Type: 8 Size: 52
          . . . . Col: DISTANCE_DISCOUNT - Type: 8 Size: 52
          . . . . Col: BUSINESS_LEVEL_FACTOR - Type: 8 Size: 52
          . . . . Col: FIRSTCLASS_LEVEL_FACTOR - Type: 8 Size: 52
          . . . . Col: ECONOMY_SEATS - Type: 4 Size: 10
          . . . . Col: BUSINESS_SEATS - Type: 4 Size: 10
          . . . . Col: FIRSTCLASS_SEATS - Type: 4 Size: 10
          Got a TABLE named: CITIES
          . . Getting Exported Keys
          . . . Getting Columns
          . . . . Col: CITY_ID - Type: 4 Size: 10
          . . . . Col: CITY_NAME - Type: 12 Size: 24
          . . . . Col: COUNTRY - Type: 12 Size: 26
          . . . . Col: AIRPORT - Type: 12 Size: 3
          . . . . Col: LANGUAGE - Type: 12 Size: 16
          . . . . Col: COUNTRY_ISO_CODE - Type: 1 Size: 2
          Got a TABLE named: CIUDAD_DE_MEXICO
          . . Getting Exported Keys
          . . . Getting Columns
          . . . . Col: NOMBRE - Type: 12 Size: 24
          . . . . Col: ESTADO - Type: 12 Size: 24
          . . . . Col: EXCEPCI?N - Type: 4 Size: 10
          Got a TABLE named: CIUDAD_DE_MEXICO2
          . . Getting Exported Keys
          . . . Getting Columns
          . . . . Col: NOMBRE - Type: 12 Size: 24
          . . . . Col: ESTADO - Type: 12 Size: 24
          . . . . Col: EXCEPCI?N - Type: 4 Size: 10

          == REST of OUTPUT not included

          Show
          Stan Bradbury added a comment - Performed a basic test on a database (toursdb) created with territory=territory=es_MX - a simple progam that lists tables, exported keys and columns works fine (DbMD.getTables then getExportedKeys then getColumns). This could be a test issue or under a specific configuration. Since basic functionality is not impaired I think the priority of this issue can be lowered. Attached is a zipfile with the simple test program and toursDB created with es_MX territory for any one who might find this helpful. Db build: ij> connect 'jdbc:derby:work\dbs\toursMx;create=true;territory=es_MX'; ij> run 'ToursDB_schema.sql'; ij> run 'loadCOUNTRIES.sql'; ij> exit; %% java DBMetaData2 Loaded the derby JDBC driver. Get Tables Results Loop Got a TABLE named: AIRLINES . . Getting Exported Keys . . . Getting Columns . . . . Col: AIRLINE - Type: 1 Size: 2 . . . . Col: AIRLINE_FULL - Type: 12 Size: 24 . . . . Col: BASIC_RATE - Type: 8 Size: 52 . . . . Col: DISTANCE_DISCOUNT - Type: 8 Size: 52 . . . . Col: BUSINESS_LEVEL_FACTOR - Type: 8 Size: 52 . . . . Col: FIRSTCLASS_LEVEL_FACTOR - Type: 8 Size: 52 . . . . Col: ECONOMY_SEATS - Type: 4 Size: 10 . . . . Col: BUSINESS_SEATS - Type: 4 Size: 10 . . . . Col: FIRSTCLASS_SEATS - Type: 4 Size: 10 Got a TABLE named: CITIES . . Getting Exported Keys . . . Getting Columns . . . . Col: CITY_ID - Type: 4 Size: 10 . . . . Col: CITY_NAME - Type: 12 Size: 24 . . . . Col: COUNTRY - Type: 12 Size: 26 . . . . Col: AIRPORT - Type: 12 Size: 3 . . . . Col: LANGUAGE - Type: 12 Size: 16 . . . . Col: COUNTRY_ISO_CODE - Type: 1 Size: 2 Got a TABLE named: CIUDAD_DE_MEXICO . . Getting Exported Keys . . . Getting Columns . . . . Col: NOMBRE - Type: 12 Size: 24 . . . . Col: ESTADO - Type: 12 Size: 24 . . . . Col: EXCEPCI?N - Type: 4 Size: 10 Got a TABLE named: CIUDAD_DE_MEXICO2 . . Getting Exported Keys . . . Getting Columns . . . . Col: NOMBRE - Type: 12 Size: 24 . . . . Col: ESTADO - Type: 12 Size: 24 . . . . Col: EXCEPCI?N - Type: 4 Size: 10 == REST of OUTPUT not included
          Hide
          Stan Bradbury added a comment -

          Simplistic test case using DatabaseMetaData

          Show
          Stan Bradbury added a comment - Simplistic test case using DatabaseMetaData
          Hide
          Stan Bradbury added a comment -

          Simplistic test case with proper license / rights assignment

          Show
          Stan Bradbury added a comment - Simplistic test case with proper license / rights assignment
          Hide
          Mamta A. Satoor added a comment -

          I have started looking at this Jira entry since yesterday. Need to do more research before I can say what it takes to fix it.

          Show
          Mamta A. Satoor added a comment - I have started looking at this Jira entry since yesterday. Need to do more research before I can say what it takes to fix it.
          Hide
          Myrna van Lunteren added a comment -

          looks like you're actually working on this mamta, thx.

          Show
          Myrna van Lunteren added a comment - looks like you're actually working on this mamta, thx.
          Hide
          Mamta A. Satoor added a comment -

          Stan, the database you created does not have the collation=TERRITORY_BASED attribute and that is why you couldn't reproduce the problem. Once I create the database with that attribute, the very useful program provided by you gives the same exception that Dan is running into. But I do appreciate your eg since it isolates the problem and will make it easier for debugging.

          Show
          Mamta A. Satoor added a comment - Stan, the database you created does not have the collation=TERRITORY_BASED attribute and that is why you couldn't reproduce the problem. Once I create the database with that attribute, the very useful program provided by you gives the same exception that Dan is running into. But I do appreciate your eg since it isolates the problem and will make it easier for debugging.
          Hide
          Mamta A. Satoor added a comment -

          The metadata query for getTables in trunk is as follows
          SELECT CAST ('' AS VARCHAR(128)) AS TABLE_CAT, \
          SCHEMANAME AS TABLE_SCHEM, \
          TABLENAME AS TABLE_NAME, \
          (CAST (RTRIM(TABLE_TYPE) AS VARCHAR(12))) \
          AS TABLE_TYPE, CAST ('' AS VARCHAR(128)) AS REMARKS, \
          CAST (NULL AS VARCHAR(128)) AS TYPE_CAT, \
          CAST (NULL AS VARCHAR(128)) AS TYPE_SCHEM, \
          CAST (NULL AS VARCHAR(128)) AS TYPE_NAME, \
          CAST (NULL AS VARCHAR(128)) AS SELF_REFERENCING_COL_NAME, \
          CAST (NULL AS VARCHAR(128)) AS REF_GENERATION \
          FROM \
          SYS.SYSTABLES, \
          SYS.SYSSCHEMAS, \
          (VALUES ('T','TABLE'), ('S','SYSTEM TABLE'), \
          ('V', 'VIEW'), ('A', 'SYNONYM')) T(TTABBREV,TABLE_TYPE) \
          WHERE (TTABBREV=TABLETYPE \
          AND (SYS.SYSTABLES.SCHEMAID = SYS.SYSSCHEMAS.SCHEMAID) \
          AND ((1=1) OR ? IS NOT NULL) \
          AND (SYS.SYSSCHEMAS.SCHEMANAME LIKE ?) \
          AND (TABLENAME LIKE ?))

          The problem occurs because of VALUES clause which uses character string constants. These character string constants in Derby take their collation from the current compilation schema and this happens in CharConstantNode.bindExpression. I put some printlns in that method and found that the current compilation schema is whatever the current schema is when this metadata query gets run. So, if the getTables is run in user schema, the current compilation schema ends up being user schema and hence the collation type of character string constants in the query end up being territory based. When such character string constants are later compared against character string columns from SYS schema in the getTable query (TTABBREV=TABLETYPE), it results in an exception because of collation mismatch. If getTables is run from SYS schema, the collations of character string constants and character string columns match and hence no exception is thrown.

          SYSSTATEMENTS table has a column called COMPILATION SCHEMAID but that column is not used at all in the logic above. On a brand new database, this column has schemaid for SYS for getTables.

          I have to admit I don't understand why this metadata query may have worked earlier (DERBY-2656) if it was run from a user schema.

          I tried debugging in 10.2 codeline where we do not have collation support but I wanted to check what is the current compilation schema for metadata queries that get recompiled and found the current compilation schema behavior there to be same as the one in main codeline.

          I am at lost at this point as to what paths I should take in fixing the problem. Couple I can think of are as follows
          1)Have Derby somehow use the COMPILATION SCHEMAID from SYSSTATEMENTS table while recompiling the metadata queries. This might take some time to implement. At this point, I don't know how long.
          2)For the short term, fix the metadata queries to use CAST so that we are not dependent on what schema the queries are run from. I have this change made in my codeline for all the metadata queries that use character string constants for comparison. Specifically, for getTables, the ugly query above can be made uglier by using CAST but it will fix the problem.
          SELECT CAST ('' AS VARCHAR(128)) AS TABLE_CAT, \
          SCHEMANAME AS TABLE_SCHEM, \
          TABLENAME AS TABLE_NAME, \
          (CAST (RTRIM(TABLE_TYPE) AS VARCHAR(12))) \
          AS TABLE_TYPE, CAST ('' AS VARCHAR(128)) AS REMARKS, \
          CAST (NULL AS VARCHAR(128)) AS TYPE_CAT, \
          CAST (NULL AS VARCHAR(128)) AS TYPE_SCHEM, \
          CAST (NULL AS VARCHAR(128)) AS TYPE_NAME, \
          CAST (NULL AS VARCHAR(128)) AS SELF_REFERENCING_COL_NAME, \
          CAST (NULL AS VARCHAR(128)) AS REF_GENERATION \
          FROM \
          SYS.SYSTABLES, \
          SYS.SYSSCHEMAS, \
          (VALUES ('T','TABLE'), ('S','SYSTEM TABLE'), \
          ('V', 'VIEW'), ('A', 'SYNONYM')) T(TTABBREV,TABLE_TYPE) \
          WHERE (TTABBREV=CAST(TABLETYPE AS CHAR(1)) – NOTICE THE CAST ON THIS LINE \
          AND (SYS.SYSTABLES.SCHEMAID = SYS.SYSSCHEMAS.SCHEMAID) \
          AND ((1=1) OR ? IS NOT NULL) \
          AND (SYS.SYSSCHEMAS.SCHEMANAME LIKE ?) \
          AND (TABLENAME LIKE ?))

          Comments?

          Show
          Mamta A. Satoor added a comment - The metadata query for getTables in trunk is as follows SELECT CAST ('' AS VARCHAR(128)) AS TABLE_CAT, \ SCHEMANAME AS TABLE_SCHEM, \ TABLENAME AS TABLE_NAME, \ (CAST (RTRIM(TABLE_TYPE) AS VARCHAR(12))) \ AS TABLE_TYPE, CAST ('' AS VARCHAR(128)) AS REMARKS, \ CAST (NULL AS VARCHAR(128)) AS TYPE_CAT, \ CAST (NULL AS VARCHAR(128)) AS TYPE_SCHEM, \ CAST (NULL AS VARCHAR(128)) AS TYPE_NAME, \ CAST (NULL AS VARCHAR(128)) AS SELF_REFERENCING_COL_NAME, \ CAST (NULL AS VARCHAR(128)) AS REF_GENERATION \ FROM \ SYS.SYSTABLES, \ SYS.SYSSCHEMAS, \ (VALUES ('T','TABLE'), ('S','SYSTEM TABLE'), \ ('V', 'VIEW'), ('A', 'SYNONYM')) T(TTABBREV,TABLE_TYPE) \ WHERE (TTABBREV=TABLETYPE \ AND (SYS.SYSTABLES.SCHEMAID = SYS.SYSSCHEMAS.SCHEMAID) \ AND ((1=1) OR ? IS NOT NULL) \ AND (SYS.SYSSCHEMAS.SCHEMANAME LIKE ?) \ AND (TABLENAME LIKE ?)) The problem occurs because of VALUES clause which uses character string constants. These character string constants in Derby take their collation from the current compilation schema and this happens in CharConstantNode.bindExpression. I put some printlns in that method and found that the current compilation schema is whatever the current schema is when this metadata query gets run. So, if the getTables is run in user schema, the current compilation schema ends up being user schema and hence the collation type of character string constants in the query end up being territory based. When such character string constants are later compared against character string columns from SYS schema in the getTable query (TTABBREV=TABLETYPE), it results in an exception because of collation mismatch. If getTables is run from SYS schema, the collations of character string constants and character string columns match and hence no exception is thrown. SYSSTATEMENTS table has a column called COMPILATION SCHEMAID but that column is not used at all in the logic above. On a brand new database, this column has schemaid for SYS for getTables. I have to admit I don't understand why this metadata query may have worked earlier ( DERBY-2656 ) if it was run from a user schema. I tried debugging in 10.2 codeline where we do not have collation support but I wanted to check what is the current compilation schema for metadata queries that get recompiled and found the current compilation schema behavior there to be same as the one in main codeline. I am at lost at this point as to what paths I should take in fixing the problem. Couple I can think of are as follows 1)Have Derby somehow use the COMPILATION SCHEMAID from SYSSTATEMENTS table while recompiling the metadata queries. This might take some time to implement. At this point, I don't know how long. 2)For the short term, fix the metadata queries to use CAST so that we are not dependent on what schema the queries are run from. I have this change made in my codeline for all the metadata queries that use character string constants for comparison. Specifically, for getTables, the ugly query above can be made uglier by using CAST but it will fix the problem. SELECT CAST ('' AS VARCHAR(128)) AS TABLE_CAT, \ SCHEMANAME AS TABLE_SCHEM, \ TABLENAME AS TABLE_NAME, \ (CAST (RTRIM(TABLE_TYPE) AS VARCHAR(12))) \ AS TABLE_TYPE, CAST ('' AS VARCHAR(128)) AS REMARKS, \ CAST (NULL AS VARCHAR(128)) AS TYPE_CAT, \ CAST (NULL AS VARCHAR(128)) AS TYPE_SCHEM, \ CAST (NULL AS VARCHAR(128)) AS TYPE_NAME, \ CAST (NULL AS VARCHAR(128)) AS SELF_REFERENCING_COL_NAME, \ CAST (NULL AS VARCHAR(128)) AS REF_GENERATION \ FROM \ SYS.SYSTABLES, \ SYS.SYSSCHEMAS, \ (VALUES ('T','TABLE'), ('S','SYSTEM TABLE'), \ ('V', 'VIEW'), ('A', 'SYNONYM')) T(TTABBREV,TABLE_TYPE) \ WHERE (TTABBREV=CAST(TABLETYPE AS CHAR(1)) – NOTICE THE CAST ON THIS LINE \ AND (SYS.SYSTABLES.SCHEMAID = SYS.SYSSCHEMAS.SCHEMAID) \ AND ((1=1) OR ? IS NOT NULL) \ AND (SYS.SYSSCHEMAS.SCHEMANAME LIKE ?) \ AND (TABLENAME LIKE ?)) Comments?
          Hide
          Daniel John Debrunner added a comment -

          I don't think the second option leads to the correct behaviour. Won't it use the schema of the current database which can be territory based which will be incorrect for meta-data queries.

          I thought the compilation schema was required for stored prepared statements (plans), which are also used to trigger actions statements. The compilation schema must be correct so that any unqualified names in the statement resolves to the intended objects, and is not dependent on the current schema where the trigger is fired.

          Show
          Daniel John Debrunner added a comment - I don't think the second option leads to the correct behaviour. Won't it use the schema of the current database which can be territory based which will be incorrect for meta-data queries. I thought the compilation schema was required for stored prepared statements (plans), which are also used to trigger actions statements. The compilation schema must be correct so that any unqualified names in the statement resolves to the intended objects, and is not dependent on the current schema where the trigger is fired.
          Hide
          Mamta A. Satoor added a comment -

          I am starting to derbug to see what is happening with compilation schema not being SYS.

          It looks like getTables is treated differently than other stored prepared statements in EmbedDatabaseMetaData. For instance, for getTablePrivileges, we try to get the already prepared query(EmbedDatabaseMetaData.getTablePrivileges) from system tables as shown below.
          PreparedStatement s = getPreparedQuery("getTablePrivileges");

          For getTables, we are bypassing the system table and instead it appears that we are trying to compile getTables's metadata query like we would any other query
          PreparedStatement s =getEmbedConnection().prepareMetaDataStatement(whereClauseTail.toString());
          That might be the cause of the problem that getTables's metadata query does not get compiled in SYS schema. Note that getTables does try to modify the metadata query text by appending an optional additional condition to WHERE clause and it appends an ORDER BY. Maybe that's why it can't use the system table. I am not sure. I will continue debugging. If anyone knows about this part of the code, will like to hear to their input.

          Show
          Mamta A. Satoor added a comment - I am starting to derbug to see what is happening with compilation schema not being SYS. It looks like getTables is treated differently than other stored prepared statements in EmbedDatabaseMetaData. For instance, for getTablePrivileges, we try to get the already prepared query(EmbedDatabaseMetaData.getTablePrivileges) from system tables as shown below. PreparedStatement s = getPreparedQuery("getTablePrivileges"); For getTables, we are bypassing the system table and instead it appears that we are trying to compile getTables's metadata query like we would any other query PreparedStatement s =getEmbedConnection().prepareMetaDataStatement(whereClauseTail.toString()); That might be the cause of the problem that getTables's metadata query does not get compiled in SYS schema. Note that getTables does try to modify the metadata query text by appending an optional additional condition to WHERE clause and it appends an ORDER BY. Maybe that's why it can't use the system table. I am not sure. I will continue debugging. If anyone knows about this part of the code, will like to hear to their input.
          Hide
          Mamta A. Satoor added a comment -

          getUDTs is implemented the same way as getTables, ie we bypass going to the system table SYSSTATEMENTS for both of them. The strange thing is it appears that we do not modify the metadata query associated with getUDTs in any ways but we still do not go to SYSSTATEMENTS, Just thought would share this piece of info.

          Show
          Mamta A. Satoor added a comment - getUDTs is implemented the same way as getTables, ie we bypass going to the system table SYSSTATEMENTS for both of them. The strange thing is it appears that we do not modify the metadata query associated with getUDTs in any ways but we still do not go to SYSSTATEMENTS, Just thought would share this piece of info.
          Hide
          Mamta A. Satoor added a comment -

          Well some more progress on this Jira entry. Here are my findings

          I am pretty confident that the problem exists only for getTables and getUDTs metadata calls because those 2 calls don't go through SYSSTATEMENTS. I tried getProcedures which does character string literal comparison with system character columns and it works fine because getProcedures goes through SYSSTATMENTS and compiles in SYS schema even though the current schema may be a user schema.

          Show
          Mamta A. Satoor added a comment - Well some more progress on this Jira entry. Here are my findings I am pretty confident that the problem exists only for getTables and getUDTs metadata calls because those 2 calls don't go through SYSSTATEMENTS. I tried getProcedures which does character string literal comparison with system character columns and it works fine because getProcedures goes through SYSSTATMENTS and compiles in SYS schema even though the current schema may be a user schema.
          Hide
          Mamta A. Satoor added a comment -

          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?

          Show
          Mamta A. Satoor added a comment - 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?
          Hide
          Stan Bradbury added a comment -

          Database metadata calls are used a lot to provide database independence and without this problem fixed TERRITORY_BASED collation (other than the default) will not be able to be used in these systems. This preoblem is certainly a Blocker for this feature but should the release be blocked? There is a proposed fix for the problem and I would like to see this implemented ASAP.

          I propose that the 10.3.1.2 release go forward with this problem well documented and that an official release (10.3.2.x) be created within 4-6 weeks that corrects this and any other serious problems that are reported during this 'shake-down' period.

          What say you?

          Show
          Stan Bradbury added a comment - Database metadata calls are used a lot to provide database independence and without this problem fixed TERRITORY_BASED collation (other than the default) will not be able to be used in these systems. This preoblem is certainly a Blocker for this feature but should the release be blocked? There is a proposed fix for the problem and I would like to see this implemented ASAP. I propose that the 10.3.1.2 release go forward with this problem well documented and that an official release (10.3.2.x) be created within 4-6 weeks that corrects this and any other serious problems that are reported during this 'shake-down' period. What say you?
          Hide
          Mamta A. Satoor added a comment -

          Stan, I just wanted to mention that broken metadata calls are getTables and getUDTs and not all the metadata calls. This fact certainly does not make this bug less critical but I just wanted the community to know what is broken in metadata calls.

          Show
          Mamta A. Satoor added a comment - Stan, I just wanted to mention that broken metadata calls are getTables and getUDTs and not all the metadata calls. This fact certainly does not make this bug less critical but I just wanted the community to know what is broken in metadata calls.
          Hide
          Mamta A. Satoor added a comment -

          Checked in fix for this bug in main with revision 557334. The commit changes were as follows (Myrna, can I migrate this change to 10.3 codeline?)

          DERBY-2896

          Metadata calls getTables and getUDTs were failing when run from a user schema in a territory based collated database.
          The reason for it is that these metadata calls were not getting compiled in SYS schema when they were executed from
          a user schema. Metadata calls should always compile in SYS schema no matter what the current schema might be. The
          reason getTables was not getting compiled in SYS schema was because we were trying to modify it's metadata sql on
          the fly and then were compiling that modified sql in whatever the current schema might be. I have changed the
          metadata sql for getTables in metadata.properties so that we do not need to modify it on the fly anymore. This will
          allow getTables to follow the same codepath as other metadata queries which will also ensure that the sql gets
          compiled in SYS schema.

          As for getUDTs, it was merely a coding bug that we didn't follow the same logic as other metadata queries for it.
          I have changed getUDTs implementation to follow the same codepath as other metadata queries.

          -This line, and those below, will be ignored-

          M java/engine/org/apache/derby/impl/jdbc/metadata.properties
          M java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java

          Show
          Mamta A. Satoor added a comment - Checked in fix for this bug in main with revision 557334. The commit changes were as follows (Myrna, can I migrate this change to 10.3 codeline?) DERBY-2896 Metadata calls getTables and getUDTs were failing when run from a user schema in a territory based collated database. The reason for it is that these metadata calls were not getting compiled in SYS schema when they were executed from a user schema. Metadata calls should always compile in SYS schema no matter what the current schema might be. The reason getTables was not getting compiled in SYS schema was because we were trying to modify it's metadata sql on the fly and then were compiling that modified sql in whatever the current schema might be. I have changed the metadata sql for getTables in metadata.properties so that we do not need to modify it on the fly anymore. This will allow getTables to follow the same codepath as other metadata queries which will also ensure that the sql gets compiled in SYS schema. As for getUDTs, it was merely a coding bug that we didn't follow the same logic as other metadata queries for it. I have changed getUDTs implementation to follow the same codepath as other metadata queries. - This line, and those below, will be ignored - M java/engine/org/apache/derby/impl/jdbc/metadata.properties M java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
          Hide
          Knut Anders Hatlen added a comment -

          I haven't followed this discussion closely, but I'd just mention that before you port the fix to 10.3, you might want to have a look at http://wiki.apache.org/db-derby/MetadataUpgrade, the section about Maintenance and Point Releases in particular. The changes in metadata.properties will not be picked up when you upgrade from 10.3.1.x to 10.3.2.x. I don't know if that's a problem, but you may have to do something more exotic to make it work in that scenario.

          Show
          Knut Anders Hatlen added a comment - I haven't followed this discussion closely, but I'd just mention that before you port the fix to 10.3, you might want to have a look at http://wiki.apache.org/db-derby/MetadataUpgrade , the section about Maintenance and Point Releases in particular. The changes in metadata.properties will not be picked up when you upgrade from 10.3.1.x to 10.3.2.x. I don't know if that's a problem, but you may have to do something more exotic to make it work in that scenario.
          Hide
          Kathey Marsden added a comment -

          >The changes in metadata.properties will not be picked up when you upgrade from 10.3.1.x to 10.3.2.x.

          This filed as DERBY-1107 and I think is a good reason to have a new release candidate. I think other critical issues such as DERBY-2437 and the regression DERBY-2892 might be worth waiting for too if they can be fixed in short order. I wouldn't veto a release at this point but would probably vote -0.

          Show
          Kathey Marsden added a comment - >The changes in metadata.properties will not be picked up when you upgrade from 10.3.1.x to 10.3.2.x. This filed as DERBY-1107 and I think is a good reason to have a new release candidate. I think other critical issues such as DERBY-2437 and the regression DERBY-2892 might be worth waiting for too if they can be fixed in short order. I wouldn't veto a release at this point but would probably vote -0.
          Hide
          Mamta A. Satoor added a comment -

          Ported the changes from main into 10.3 codeline (revision 557405) Will look into metadata upgrade issue if it turns out that my changes didn't make into 10.3.1.x codeline.

          Show
          Mamta A. Satoor added a comment - Ported the changes from main into 10.3 codeline (revision 557405) Will look into metadata upgrade issue if it turns out that my changes didn't make into 10.3.1.x codeline.
          Hide
          Kathey Marsden added a comment - - edited

          Kathey said
          >When synching up to the latest 10.4, and running FullCollationTests, I am still seeing some >(but not as many) of this error. See full report attached to DERBY-2656

          This was a false alarm. getTables() seems to be ok. New output is attached to DERBY-2656:FullCollationTests_out.txt

          Kathey

          Show
          Kathey Marsden added a comment - - edited Kathey said >When synching up to the latest 10.4, and running FullCollationTests, I am still seeing some >(but not as many) of this error. See full report attached to DERBY-2656 This was a false alarm. getTables() seems to be ok. New output is attached to DERBY-2656 :FullCollationTests_out.txt Kathey
          Hide
          Dyre Tjeldvoll added a comment -

          Blocker issues that have been 'Resolved' for a long time (6 months+)

          Show
          Dyre Tjeldvoll added a comment - Blocker issues that have been 'Resolved' for a long time (6 months+)

            People

            • Assignee:
              Mamta A. Satoor
              Reporter:
              Daniel John Debrunner
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development