db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ma...@apache.org
Subject svn commit: r553787 - in /db/derby/code/branches/10.3/java: engine/org/apache/derby/impl/sql/compile/TernaryOperatorNode.java testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
Date Fri, 06 Jul 2007 08:24:36 GMT
Author: mamta
Date: Fri Jul  6 01:24:35 2007
New Revision: 553787

URL: http://svn.apache.org/viewvc?view=rev&rev=553787
Log:
Merging revision 553784 from main into 10.3.1.1 codeline. The commit comments for main were
as follows

DERBY-2777

Currently, the parameters in LOCATE clause always pickup their collation from the compilation
schema. That logic is not
complete. I am fixing that logic here along with addition of some tests.

For the sake of explanation, let me use the following syntax for LOCATE clause
LOCATE (receiver, leftOperand)
With the fix in this patch, if receiver is a parameter, it will set it's collation using following
logic
1)check if leftOperand is not a parameter. If yes, then receiver will pick up collation from
leftOperand. If not, goto step 2
2)receiver picks up the collation of the compilation schema because everything in the LOCATE
clause is ?

Next, if leftOperand is a parameter, it will set it's collation using receiver. By this time,
even if receiver is a
parameter, we have set correct collation for receiver and hence leftOperand can simply rely
on receiver for correct
collation IF leftOperand is a parameter.



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

Modified: db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/sql/compile/TernaryOperatorNode.java
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/sql/compile/TernaryOperatorNode.java?view=diff&rev=553787&r1=553786&r2=553787
==============================================================================
--- db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/sql/compile/TernaryOperatorNode.java
(original)
+++ db/derby/code/branches/10.3/java/engine/org/apache/derby/impl/sql/compile/TernaryOperatorNode.java
Fri Jul  6 01:24:35 2007
@@ -623,6 +623,9 @@
 	}
 	/**
 	 * Bind locate operator
+	 * The variable receiver is the string which will searched
+	 * The variable leftOperand is the search character that will looked in the
+	 *     receiver variable.
 	 *
 	 * @return	The new top of the expression tree.
 	 *
@@ -643,18 +646,22 @@
 			if( leftOperand.requiresTypeFromContext())
 			{
 				receiver.setType(getVarcharDescriptor());
+	            //Since both receiver and leftOperands are parameters, use the
+				//collation of compilation schema for receiver.
+				receiver.setCollationUsingCompilationSchema(
+						StringDataValue.COLLATION_DERIVATION_IMPLICIT);            	
 			}
 			else
 			{
 				if( leftOperand.getTypeId().isStringTypeId() )
 				{
+					//Since the leftOperand is not a parameter, receiver will
+					//get it's collation from leftOperand through following
+					//setType method
 					receiver.setType(
 							         leftOperand.getTypeServices());
 				}
 			}
-			//collation of ? operand should be same as the compilation schema
-			receiver.setCollationUsingCompilationSchema(
-					StringDataValue.COLLATION_DERIVATION_IMPLICIT);
 		}
 							                            
 		/*
@@ -675,9 +682,14 @@
 							         receiver.getTypeServices());
 				}
 			}
-			//collation of ? operand should be same as the compilation schema
-			leftOperand.setCollationUsingCompilationSchema(
-					StringDataValue.COLLATION_DERIVATION_IMPLICIT);
+			//collation of ? operand should be picked up from the context.
+            //By the time we come here, receiver will have correct collation
+            //set on it and hence we can rely on it to get correct collation
+            //for this ? 
+			leftOperand.getTypeServices().setCollationDerivation(
+					receiver.getTypeServices().getCollationDerivation());
+			leftOperand.getTypeServices().setCollationType(
+        			receiver.getTypeServices().getCollationType());            	
 		}
 
 		/*

Modified: db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java?view=diff&rev=553787&r1=553786&r2=553787
==============================================================================
--- db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
(original)
+++ db/derby/code/branches/10.3/java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
Fri Jul  6 01:24:35 2007
@@ -858,6 +858,22 @@
     //No rows returned because the result of TRIM is going to be 'YSCOLUMNS'
     JDBC.assertEmpty(rs);
     
+    //Do parameter testing for LOCATE
+    //Following will fail because 'LOOKFORME' has collation of territory based
+    //but TABLENAME has collation of UCS_BASIC and hence LOCATE will fail 
+    //because the collation types of it's two operands do not match
+    ps = conn.prepareStatement("SELECT TABLENAME FROM SYS.SYSTABLES WHERE " +
+    		" LOCATE(?, TABLENAME) != 0");
+    ps.setString(1, "ABC");
+    rs = ps.executeQuery();
+    JDBC.assertEmpty(rs);
+    //Just switch the parameter position and try the sql again
+    ps = conn.prepareStatement("SELECT TABLENAME FROM SYS.SYSTABLES WHERE " +
+    		" LOCATE(TABLENAME, ?) != 0");
+    ps.setString(1, "ABC");
+    rs = ps.executeQuery();
+    JDBC.assertEmpty(rs);
+    
     //Do parameter testing with IN and subquery
     //Following will work just fine because ? will take it's collation from the
     //context which in this case will be collation of TABLENAME which has 



Mime
View raw message