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 "Mamta A. Satoor (JIRA)" <ji...@apache.org> on 2007/07/03 20:49:04 UTC
[jira] Created: (DERBY-2894) calling DatabaseMetaData.getColumns()
with % for matching column character in a territory based collated db does
not work in 1.4.2 jvms
calling DatabaseMetaData.getColumns() with % for matching column character in a territory based collated db does not work in 1.4.2 jvms
---------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-2894
URL: https://issues.apache.org/jira/browse/DERBY-2894
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.3.0.0
Reporter: Mamta A. Satoor
calling DatabaseMetaData.getColumns(null, "APP", "CUSTOMER", "%") returns no rows for a valid APP.CUSTOMER table
in ibm142 and sun142 jvms, for databases created with territory based collation, fails in all 3 cases we test in the
CollationTest2.java junit test.
Since this is a system catalog query I am surprised the result is affected at all by collation, so there may be a derby bug
in the metadata routines, or elsewhere. Mamta, could you comment if you believe this should work already - or if there
is more work to do in this area.
I will soon checkin a test case into the CollationTest2.java unit test that shows this. For now I will either comment out the
entire test, or if I can figure out how to not run it on 142 I will do that.
This issue was first reported as DERBY-2703 but it was reported as a subtask of DERBY-1478. But since it really is a bug, I am re-reporting it at the top level so it can be tracked as open bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2894) calling DatabaseMetaData.getColumns()
with % for matching column character in a territory based collated db does
not work in 1.4.2 jvms
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali reassigned DERBY-2894:
-------------------------------------
Assignee: Mike Matrigali
> calling DatabaseMetaData.getColumns() with % for matching column character in a territory based collated db does not work in 1.4.2 jvms
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2894
> URL: https://issues.apache.org/jira/browse/DERBY-2894
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mamta A. Satoor
> Assignee: Mike Matrigali
>
> calling DatabaseMetaData.getColumns(null, "APP", "CUSTOMER", "%") returns no rows for a valid APP.CUSTOMER table
> in ibm142 and sun142 jvms, for databases created with territory based collation, fails in all 3 cases we test in the
> CollationTest2.java junit test.
> Since this is a system catalog query I am surprised the result is affected at all by collation, so there may be a derby bug
> in the metadata routines, or elsewhere. Mamta, could you comment if you believe this should work already - or if there
> is more work to do in this area.
> I will soon checkin a test case into the CollationTest2.java unit test that shows this. For now I will either comment out the
> entire test, or if I can figure out how to not run it on 142 I will do that.
> This issue was first reported as DERBY-2703 but it was reported as a subtask of DERBY-1478. But since it really is a bug, I am re-reporting it at the top level so it can be tracked as open bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2894) calling
DatabaseMetaData.getColumns() with % for matching column character in a
territory based collated db does not work in 1.4.2 jvms
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511667 ]
Mamta A. Satoor commented on DERBY-2894:
----------------------------------------
Can someone try this in sun142 environment because I just uncommented following from CollationTest2.runDERBY_2703 and didn't see any problems when running CollationTest2 with Sun jdk142
//if (is142JVM())
// return;
$ which java
c:/p4clients/main/jdk142/bin/java.exe
> calling DatabaseMetaData.getColumns() with % for matching column character in a territory based collated db does not work in 1.4.2 jvms
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2894
> URL: https://issues.apache.org/jira/browse/DERBY-2894
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mamta A. Satoor
>
> calling DatabaseMetaData.getColumns(null, "APP", "CUSTOMER", "%") returns no rows for a valid APP.CUSTOMER table
> in ibm142 and sun142 jvms, for databases created with territory based collation, fails in all 3 cases we test in the
> CollationTest2.java junit test.
> Since this is a system catalog query I am surprised the result is affected at all by collation, so there may be a derby bug
> in the metadata routines, or elsewhere. Mamta, could you comment if you believe this should work already - or if there
> is more work to do in this area.
> I will soon checkin a test case into the CollationTest2.java unit test that shows this. For now I will either comment out the
> entire test, or if I can figure out how to not run it on 142 I will do that.
> This issue was first reported as DERBY-2703 but it was reported as a subtask of DERBY-1478. But since it really is a bug, I am re-reporting it at the top level so it can be tracked as open bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2894) calling DatabaseMetaData.getColumns()
with % for matching column character in a territory based collated db does
not work in 1.4.2 jvms
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali resolved DERBY-2894.
-----------------------------------
Resolution: Cannot Reproduce
Fix Version/s: 10.3.1.4
This issue no longer reproduces, it must have been fixed by subsequent Collation work, but not sure what change.
> calling DatabaseMetaData.getColumns() with % for matching column character in a territory based collated db does not work in 1.4.2 jvms
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2894
> URL: https://issues.apache.org/jira/browse/DERBY-2894
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mamta A. Satoor
> Assignee: Mike Matrigali
> Fix For: 10.3.1.4
>
>
> calling DatabaseMetaData.getColumns(null, "APP", "CUSTOMER", "%") returns no rows for a valid APP.CUSTOMER table
> in ibm142 and sun142 jvms, for databases created with territory based collation, fails in all 3 cases we test in the
> CollationTest2.java junit test.
> Since this is a system catalog query I am surprised the result is affected at all by collation, so there may be a derby bug
> in the metadata routines, or elsewhere. Mamta, could you comment if you believe this should work already - or if there
> is more work to do in this area.
> I will soon checkin a test case into the CollationTest2.java unit test that shows this. For now I will either comment out the
> entire test, or if I can figure out how to not run it on 142 I will do that.
> This issue was first reported as DERBY-2703 but it was reported as a subtask of DERBY-1478. But since it really is a bug, I am re-reporting it at the top level so it can be tracked as open bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2894) calling DatabaseMetaData.getColumns()
with % for matching column character in a territory based collated db does
not work in 1.4.2 jvms
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-2894:
----------------------------------
I tried it out in the 10.3 branch also and the bug is fixed. I would like to back port the test change and mark this as fixed or at least no longer reproduces as soon as it has run through the publicly posted nightly runs.
> calling DatabaseMetaData.getColumns() with % for matching column character in a territory based collated db does not work in 1.4.2 jvms
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2894
> URL: https://issues.apache.org/jira/browse/DERBY-2894
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mamta A. Satoor
>
> calling DatabaseMetaData.getColumns(null, "APP", "CUSTOMER", "%") returns no rows for a valid APP.CUSTOMER table
> in ibm142 and sun142 jvms, for databases created with territory based collation, fails in all 3 cases we test in the
> CollationTest2.java junit test.
> Since this is a system catalog query I am surprised the result is affected at all by collation, so there may be a derby bug
> in the metadata routines, or elsewhere. Mamta, could you comment if you believe this should work already - or if there
> is more work to do in this area.
> I will soon checkin a test case into the CollationTest2.java unit test that shows this. For now I will either comment out the
> entire test, or if I can figure out how to not run it on 142 I will do that.
> This issue was first reported as DERBY-2703 but it was reported as a subtask of DERBY-1478. But since it really is a bug, I am re-reporting it at the top level so it can be tracked as open bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2894) calling DatabaseMetaData.getColumns()
with % for matching column character in a territory based collated db does
not work in 1.4.2 jvms
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-2894:
----------------------------------
The 2 test cases passed for me. I just reenabled the test cases to run against all jvm's in the trunk:
m2_ibm142:43>svn commit
Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\Col
lationTest2.java
Transmitting file data .
Committed revision 555421.
> calling DatabaseMetaData.getColumns() with % for matching column character in a territory based collated db does not work in 1.4.2 jvms
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2894
> URL: https://issues.apache.org/jira/browse/DERBY-2894
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mamta A. Satoor
>
> calling DatabaseMetaData.getColumns(null, "APP", "CUSTOMER", "%") returns no rows for a valid APP.CUSTOMER table
> in ibm142 and sun142 jvms, for databases created with territory based collation, fails in all 3 cases we test in the
> CollationTest2.java junit test.
> Since this is a system catalog query I am surprised the result is affected at all by collation, so there may be a derby bug
> in the metadata routines, or elsewhere. Mamta, could you comment if you believe this should work already - or if there
> is more work to do in this area.
> I will soon checkin a test case into the CollationTest2.java unit test that shows this. For now I will either comment out the
> entire test, or if I can figure out how to not run it on 142 I will do that.
> This issue was first reported as DERBY-2703 but it was reported as a subtask of DERBY-1478. But since it really is a bug, I am re-reporting it at the top level so it can be tracked as open bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.