Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: svn commit: r545621 - in /db/derby/code/trunk/java:
 engine/org/apache/derby/impl/sql/compile/LengthOperatorNode.java
 testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
Date: Fri, 08 Jun 2007 21:08:34 -0000
To: derby-commits@db.apache.org
From: mamta@apache.org
Message-Id: <20070608210834.A3C6D1A981A@eris.apache.org>

Author: mamta
Date: Fri Jun  8 14:08:33 2007
New Revision: 545621

URL: http://svn.apache.org/viewvc?view=rev&rev=545621
Log:
DERBY-2777
Fixed the combination of LENGTH operator and parameters so that the parameters take their collation from the context and not from the current
compilation schema. In fact, it appears that LENGTH operator is not allowed to take a parameter and user would get sql exception 42X36 if
LENGTH was used with a parameter. I have added a test case for that.


Modified:
    db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/LengthOperatorNode.java
    db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java

Modified: db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/LengthOperatorNode.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/LengthOperatorNode.java?view=diff&rev=545621&r1=545620&r2=545621
==============================================================================
--- db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/LengthOperatorNode.java (original)
+++ db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/LengthOperatorNode.java Fri Jun  8 14:08:33 2007
@@ -144,13 +144,13 @@
 		** According to the SQL standard, if XXX_length has a ? operand,
 		** its type is varchar with the implementation-defined maximum length
 		** for a varchar.
+		** Also, for XXX_length, it doesn't matter what is VARCHAR's collation 
+		** (since for XXX_length, no collation sensitive processing is 
+		** is required) and hence we will not worry about the collation setting
 		*/
 
 		operand.setType(DataTypeDescriptor.getBuiltInDataTypeDescriptor(parameterType, true, 
 												parameterWidth));
-		//collation of ? operand should be same as the compilation schema
-		operand.setCollationUsingCompilationSchema(
-				StringDataValue.COLLATION_DERIVATION_IMPLICIT);
 	}
 
 	/**

Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java?view=diff&rev=545621&r1=545620&r2=545621
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java Fri Jun  8 14:08:33 2007
@@ -753,7 +753,13 @@
     rs = ps.executeQuery();
     JDBC.assertEmpty(rs);
 
-    
+    //Do parameter testing for LENGTH
+    //Following query will fail because LENGTH operator is not allowed to take
+    //a parameter. I just wanted to have a test case out for the changes that
+    //are going into engine code (ie LengthOperatorNode)
+    checkPreparedStatementError(conn, "SELECT COUNT(*) FROM CUSTOMER WHERE " +
+    		" LENGTH(?) != 0", "42X36");   
+
     //Do parameter testing with COALESCE
     //following will pass because the ? inside the COALESCE will take the 
     //collation type of the other operand which is TABLENAME. The result of