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 "Mike Matrigali (JIRA)" <ji...@apache.org> on 2007/05/29 19:28:16 UTC
[jira] Created: (DERBY-2717) throw error if non-matching collation
ids in like.
throw error if non-matching collation ids in like.
--------------------------------------------------
Key: DERBY-2717
URL: https://issues.apache.org/jira/browse/DERBY-2717
Project: Derby
Issue Type: Sub-task
Reporter: Mike Matrigali
Assignee: Mike Matrigali
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2717) throw error if non-matching
collation ids in like.
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499861 ]
Mamta A. Satoor commented on DERBY-2717:
----------------------------------------
When we fix this bug, we should add some test cases for LIKE and parameters combination.
> throw error if non-matching collation ids in like.
> --------------------------------------------------
>
> Key: DERBY-2717
> URL: https://issues.apache.org/jira/browse/DERBY-2717
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
>
> LIKE should throw an error if it has mismatching params.
> Mamta gives the standard references:
> The collation rule for c1 like c2 should be same as c1 = c2 as per SQL specification.
> As per SQL spec, Section 8.5 <like predicate>, Syntax Rules 3d),
> "The collation used for <like predicate> is determined by applying Subclause 9.13, "Collation determination", with operands CVE, PC, and (if specified) EC."
> As per SQL spec, Section 8.2 <comparison predicate>, General Rules 3a),
> "Let CS be the collation as determined by Subclause 9.13, "Collation determination", for the declared types of the two character strings."
> Please let me know if you have any further questions in this area.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2717) throw error if non-matching collation
ids in like.
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali resolved DERBY-2717.
-----------------------------------
Resolution: Fixed
Fix Version/s: 10.3.0.0
Fixed with svn 543554.
Throw new error if operands of LIKE do not have matching collations.
Adds tests for this case in CollationTest2.java
> throw error if non-matching collation ids in like.
> --------------------------------------------------
>
> Key: DERBY-2717
> URL: https://issues.apache.org/jira/browse/DERBY-2717
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Fix For: 10.3.0.0
>
>
> LIKE should throw an error if it has mismatching params.
> Mamta gives the standard references:
> The collation rule for c1 like c2 should be same as c1 = c2 as per SQL specification.
> As per SQL spec, Section 8.5 <like predicate>, Syntax Rules 3d),
> "The collation used for <like predicate> is determined by applying Subclause 9.13, "Collation determination", with operands CVE, PC, and (if specified) EC."
> As per SQL spec, Section 8.2 <comparison predicate>, General Rules 3a),
> "Let CS be the collation as determined by Subclause 9.13, "Collation determination", for the declared types of the two character strings."
> Please let me know if you have any further questions in this area.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2717) throw error if non-matching collation
ids in like.
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-2717:
----------------------------------
good catch mamta. I made all the changes to be able to do this correctly and then forgot to go back and change to the top level call.
Just committed fix for this - 543590.
> throw error if non-matching collation ids in like.
> --------------------------------------------------
>
> Key: DERBY-2717
> URL: https://issues.apache.org/jira/browse/DERBY-2717
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Fix For: 10.3.0.0
>
>
> LIKE should throw an error if it has mismatching params.
> Mamta gives the standard references:
> The collation rule for c1 like c2 should be same as c1 = c2 as per SQL specification.
> As per SQL spec, Section 8.5 <like predicate>, Syntax Rules 3d),
> "The collation used for <like predicate> is determined by applying Subclause 9.13, "Collation determination", with operands CVE, PC, and (if specified) EC."
> As per SQL spec, Section 8.2 <comparison predicate>, General Rules 3a),
> "Let CS be the collation as determined by Subclause 9.13, "Collation determination", for the declared types of the two character strings."
> Please let me know if you have any further questions in this area.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2717) throw error if non-matching collation
ids in like.
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-2717:
----------------------------------
I am working on this, but just found that when I do the check the LIKE coming from getColumns() call is generating
a basic collation id LIKE a user collation constant. This is the test case call of the database metadata from the
CollationTest2. The stack looks like:
1) testEnglishCollation(org.apache.derbyTesting.functionTests.tests.lang.Collat
onTest2)java.sql.SQLException: Java exception: 'org.apache.derby.impl.sql.compi
e.ParameterNode incompatible with org.apache.derby.impl.sql.compile.CharConstan
Node: java.lang.ClassCastException'.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExcept
onFactory.java:45)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:245)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Tr
nsactionResourceImpl.java:403)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Trans
ctionResourceImpl.java:346)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnecti
n.java:1549)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChi
d.java:81)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(EmbedPreparedSt
tement.java:144)
at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Driver30.java:9
)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareMetaDataStatement(Embe
Connection.java:1872)
at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.prepareSPS(EmbedDatabas
MetaData.java:3638)
at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQueryUsingSy
temTables(EmbedDatabaseMetaData.java:3475)
at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(EmbedD
tabaseMetaData.java:3523)
at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(EmbedD
tabaseMetaData.java:3548)
at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.doGetCols(EmbedDatabase
etaData.java:1925)
at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getColumns(EmbedDatabas
MetaData.java:1897)
at org.apache.derbyTesting.functionTests.tests.lang.CollationTest2.runDERBY
2703(CollationTest2.java:1000)
at org.apache.derbyTesting.functionTests.tests.lang.CollationTest2.runTestI
er(CollationTest2.java:1883)
at org.apache.derbyTesting.functionTests.tests.lang.CollationTest2.testEngl
shCollation(CollationTest2.java:1916)
> throw error if non-matching collation ids in like.
> --------------------------------------------------
>
> Key: DERBY-2717
> URL: https://issues.apache.org/jira/browse/DERBY-2717
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
>
> LIKE should throw an error if it has mismatching params.
> Mamta gives the standard references:
> The collation rule for c1 like c2 should be same as c1 = c2 as per SQL specification.
> As per SQL spec, Section 8.5 <like predicate>, Syntax Rules 3d),
> "The collation used for <like predicate> is determined by applying Subclause 9.13, "Collation determination", with operands CVE, PC, and (if specified) EC."
> As per SQL spec, Section 8.2 <comparison predicate>, General Rules 3a),
> "Let CS be the collation as determined by Subclause 9.13, "Collation determination", for the declared types of the two character strings."
> Please let me know if you have any further questions in this area.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2717) throw error if non-matching collation
ids in like.
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-2717:
----------------------------------
Component/s: SQL
Description:
LIKE should throw an error if it has mismatching params.
Mamta gives the standard references:
The collation rule for c1 like c2 should be same as c1 = c2 as per SQL specification.
As per SQL spec, Section 8.5 <like predicate>, Syntax Rules 3d),
"The collation used for <like predicate> is determined by applying Subclause 9.13, "Collation determination", with operands CVE, PC, and (if specified) EC."
As per SQL spec, Section 8.2 <comparison predicate>, General Rules 3a),
"Let CS be the collation as determined by Subclause 9.13, "Collation determination", for the declared types of the two character strings."
Please let me know if you have any further questions in this area.
Affects Version/s: 10.3.0.0
> throw error if non-matching collation ids in like.
> --------------------------------------------------
>
> Key: DERBY-2717
> URL: https://issues.apache.org/jira/browse/DERBY-2717
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
>
> LIKE should throw an error if it has mismatching params.
> Mamta gives the standard references:
> The collation rule for c1 like c2 should be same as c1 = c2 as per SQL specification.
> As per SQL spec, Section 8.5 <like predicate>, Syntax Rules 3d),
> "The collation used for <like predicate> is determined by applying Subclause 9.13, "Collation determination", with operands CVE, PC, and (if specified) EC."
> As per SQL spec, Section 8.2 <comparison predicate>, General Rules 3a),
> "Let CS be the collation as determined by Subclause 9.13, "Collation determination", for the declared types of the two character strings."
> Please let me know if you have any further questions in this area.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2717) throw error if non-matching
collation ids in like.
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500806 ]
Mamta A. Satoor commented on DERBY-2717:
----------------------------------------
Mike, I probably didn't spend enough time on the patch to understand this but why is DataTypeDescriptor.getCollationName() not simply calling typeDescriptor.getCollationName()? Also, if we do need to keep DataTypeDescriptor.getCollationName() the way it is right now, then maybe we should use constants strings from StringDataValue for collation names rather than hardcoded strings "UCS_BASIC" and "TERRITORY_BASED".
> throw error if non-matching collation ids in like.
> --------------------------------------------------
>
> Key: DERBY-2717
> URL: https://issues.apache.org/jira/browse/DERBY-2717
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Fix For: 10.3.0.0
>
>
> LIKE should throw an error if it has mismatching params.
> Mamta gives the standard references:
> The collation rule for c1 like c2 should be same as c1 = c2 as per SQL specification.
> As per SQL spec, Section 8.5 <like predicate>, Syntax Rules 3d),
> "The collation used for <like predicate> is determined by applying Subclause 9.13, "Collation determination", with operands CVE, PC, and (if specified) EC."
> As per SQL spec, Section 8.2 <comparison predicate>, General Rules 3a),
> "Let CS be the collation as determined by Subclause 9.13, "Collation determination", for the declared types of the two character strings."
> Please let me know if you have any further questions in this area.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.