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-2950) BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern operand with type CHAR(4) and collation
Date Thu, 19 Jul 2007 16:26:06 GMT

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

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

Kathey, this thread here http://www.nabble.com/Collation-feature-discussion-tf3418026.html#a9526316
is kind of long but that's where the discussion happened for different collation rules. What
was decided at the end was following

***** Mamta Wrote *********
Rick, you and Dan have the same concern about the dynamic nature of current schema's character
set association with string literal. The main reason behind my thinking was that I didn't
want the metadata queries to break in the absence of COLLATE clause. But I had a quick off
the list talk with Dan about metadata queries and user queries and he had an excellent solution
to the problem. He recommended using the CAST function which will be able to provide the correct
character set association in metadata queries and user queries going against system tables.

 
So, the string literal will always have the USER character set associated with them (and not
current schema's character set). 
**************

Later during the implementation, rather than always using UCS_BASIC for character string literals,
we used collation of current compilation schema's character set and I entered a Jira entry
DERBY-2731 to see if we should change our implementation for string literals to take UCS_BASIC.
But in the absence of clear direction from SQL standard, we continued to use collation of
current compilation schema's character set .

As for your question about can this be changed in future, I do not think we can do it without
causing backward compatibility problems. I think whatever we decide to do for collation assignment
for string literals in this release should not be changed in future to avoid compatibility
problems. 

Please feel free to discuss your thoughts on this collation assignment issue.

> BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException:
Operand of LIKE predicate with type VARCHAR(128) and collation UCS_BASIC is not compatable
with LIKE pattern operand with type CHAR(4) and collation
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2950
>                 URL: https://issues.apache.org/jira/browse/DERBY-2950
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.4.0.0
>            Reporter: Kathey Marsden
>            Assignee: Mamta A. Satoor
>
> BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException:
Operand of LIKE predicate with type VARCHAR(128) and collation UCS_BASIC is not compatable
with LIKE pattern operand with type CHAR(4) and collation
> Full trace below:
> java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation
UCS_BASIC is not compatable with LIKE pattern operand with type CHAR(4) and collation TERRITORY_BASED.
> 	at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
> 	at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202)
> 	at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391)
> 	at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572)
> 	at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:153)
> 	at org.apache.derbyTesting.functionTests.tests.jdbcapi.BatchUpdateTest.testMinimalDDLInBatch(BatchUpdateTest.java:248)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:615)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: ERROR 42ZA2: Operand of LIKE predicate with type VARCHAR(128) and collation
UCS_BASIC is not compatable with LIKE pattern operand with type CHAR(4) and collation TERRITORY_BASED.
> 	at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:371)
> 	at org.apache.derby.impl.sql.compile.LikeEscapeOperatorNode.bindExpression(LikeEscapeOperatorNode.java:349)
> 	at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:456)
> 	at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:227)
> 	at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java:140)
> 	at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(CursorNode.java:236)
> 	at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:314)
> 	at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
> 	at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:753)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:579)
> 	... 53 more

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