db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ma...@apache.org
Subject svn commit: r545706 - in /db/derby/code/trunk/java/engine/org/apache/derby: iapi/types/DataTypeDescriptor.java impl/sql/compile/ValueNodeList.java
Date Sat, 09 Jun 2007 07:32:04 GMT
Author: mamta
Date: Sat Jun  9 00:32:03 2007
New Revision: 545706

URL: http://svn.apache.org/viewvc?view=rev&rev=545706
Log:
DERBY-2599
Committing changes explained by following paragraphs

DataTypeDescriptor has a method called getDominantType which compares itself with the DTD
passed as parameter to getDominantType and creates a new DTD with the dominant type of the
2 DTDs, But, while doing so, It was not setting the collation information on the new DTD based
on the 2 involved DTDs. I have made changes into the method which now will set the correct
collation information on the new DTD. The algorithm, as copied from the method javadoc, is
as follows 
* If dealing with character string types, then make sure to set the 
* collation info on the dominant type. Following algorithm will be used 
* for dominant DTD's collation determination. Each of the steps of the 
* algorithem have been numbered in the comments below and those same 
* numbers are used in the actual algorithm below so it is easier to 
* understand and maintain. 
* 
* Step 1 
* If the DTD for "this" node has the same collation derivation as the 
* otherDTS, then check if their collation types match too. If the 
* collation types match too, then DTD for dominant type will get the same 
* collation derivation and type. 
* 
* Step 2 
* If the collation derivation for DTD for "this" node and otherDTS do not 
* match, then check if one of them has the collation derivation of NONE. 
* If that is the case, then dominant DTD will get the collation type and 
* derivation of DTD whose collation derivation is not NONE. 
* 
* Step 3 
* If the collation derivation for DTD for "this" node and otherDTS do not 
* match, and none of them have the derivation of NONE then it means that 
* we are dealing with collation derivation of IMPLICIT and EXPLICIT and 
* hence the dominant DTD should get collation derivation of NONE. This is 
* not a possibility in Derby 10.3 because the only 2 possible collation 
* derivation supported are IMPLICIT and NONE. 
* 
* Step 4 
* If the collation derivation for DTD for "this" node and otherDTS match, 
* then check if the collation types match too. If not, then the dominant 
* DTD should get collation derivation of NONE. 


Now, note that ValueNodeList has a method called getDominantTypeServices where it could deal
with any number of DTDs to determine the dominant DTD. It calls DataTypeDescriptor.getDominantType
on 2 DTDs at a time. At the beginning, the 2 DTDs are the first two in it's vector. It gets
an intermediate dominantDTS back for those 2 DTDs. Next, it calls DataTypeDescriptor.getDominantType
with the intermediate dominantDTS and the 3rd element in it's vector and so on and so forth.
It is not enough to just use 2 DTDs at a time to determine the collation info for the final
dominantDTS. We need to consider all the DTDs in the vector together to determine the correct
collation info for the final dominantDTS. The algorithm used by ValueNodeList.getDominantTypeServices
is in that method's javadoc and included here for reference 
* Algorithm for determining collation information 
* This method will check if it is dealing with character string datatypes. 
* If yes, then it will check if all the character string datatypes have 
* the same collation derivation and collation type associated with them. 
* If not, then the resultant DTD from this method will have collation 
* derivation of NONE. If yes, then the resultant DTD from this method will 
* have the same collation derivation and collation type as all the 
* character string datatypes. 


Modified:
    db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java
    db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/ValueNodeList.java

Modified: db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java?view=diff&rev=545706&r1=545705&r2=545706
==============================================================================
--- db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java (original)
+++ db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java Sat
Jun  9 00:32:03 2007
@@ -484,6 +484,38 @@
 	 * For variable length types, the resulting type will have the
 	 * biggest max length of the 2.
 	 * If either side is nullable, then the result will also be nullable.
+	 * 
+	 * If dealing with character string types, then make sure to set the
+	 * collation info on the dominant type. Following algorithm will be used 
+	 * for dominant DTD's collation determination. Each of the steps of the 
+	 * algorithem have been numbered in the comments below and those same 
+	 * numbers are used in the actual algorithm below so it is easier to 
+	 * understand and maintain.
+	 * 
+	 * Step 1
+	 * If the DTD for "this" node has the same collation derivation as the 
+	 * otherDTS, then check if their collation types match too. If the 
+	 * collation types match too, then DTD for dominant type will get the same 
+	 * collation derivation and type.
+	 *  
+	 * Step 2
+	 * If the collation derivation for DTD for "this" node and otherDTS do not 
+	 * match, then check if one of them has the collation derivation of NONE. 
+	 * If that is the case, then dominant DTD will get the collation type and 
+	 * derivation of DTD whose collation derivation is not NONE.
+	 * 
+	 * Step 3
+	 * If the collation derivation for DTD for "this" node and otherDTS do not 
+	 * match, and none of them have the derivation of NONE then it means that 
+	 * we are dealing with collation derivation of IMPLICIT and EXPLICIT and 
+	 * hence the dominant DTD should get collation derivation of NONE. This is 
+	 * not a possibility in Derby 10.3 because the only 2 possible collation 
+	 * derivation supported are IMPLICIT and NONE.
+	 * 
+	 * Step 4
+	 * If the collation derivation for DTD for "this" node and otherDTS match, 
+	 * then check if the collation types match too. If not, then the dominant 
+	 * DTD should get collation derivation of NONE. 
 	 *
 	 * @param otherDTS	DataTypeDescriptor to compare with.
 	 * @param cf		A ClassFactory
@@ -692,6 +724,32 @@
 
 		higherType = new DataTypeDescriptor(higherType, 
 				precision, scale, nullable, maximumWidth);
+
+		//Set collation info on the DTD for dominant type if it is string type
+		//The algorithm used is explained in this method's javadoc
+		if (higherType.getTypeId().isStringTypeId()) {
+			if (getCollationDerivation() != otherDTS.getCollationDerivation()) {
+				if (getCollationDerivation() == StringDataValue.COLLATION_DERIVATION_NONE) {
+					//Step 2
+					higherType.setCollationDerivation(otherDTS.getCollationDerivation());					
+					higherType.setCollationType(otherDTS.getCollationType());					
+				} else if (otherDTS.getCollationDerivation() == StringDataValue.COLLATION_DERIVATION_NONE)
{
+					//Step 2
+					higherType.setCollationDerivation(getCollationDerivation());					
+					higherType.setCollationType(getCollationType());										
+				} else {
+					//Step 3
+					higherType.setCollationDerivation(StringDataValue.COLLATION_DERIVATION_NONE);					
+				}
+			} else if (getCollationType() != otherDTS.getCollationType())
+				//Step 4
+				higherType.setCollationDerivation(StringDataValue.COLLATION_DERIVATION_NONE);	
+			else {
+				//Step 1
+				higherType.setCollationDerivation(getCollationDerivation());					
+				higherType.setCollationType(getCollationType());									
+			}
+		}
 
 		return higherType;
 	}

Modified: db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/ValueNodeList.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/ValueNodeList.java?view=diff&rev=545706&r1=545705&r2=545706
==============================================================================
--- db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/ValueNodeList.java (original)
+++ db/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/ValueNodeList.java Sat
Jun  9 00:32:03 2007
@@ -140,8 +140,12 @@
 	}
 
 	/**
-	 * Get the dominant DataTypeServices from the elements in the list. This 
-	 * method will also check if it is dealing with character string datatypes.
+	 * Get the dominant DataTypeServices from the elements in the list. This
+	 * method will also set the correct collation information on the dominant
+	 * DataTypeService.
+	 *  
+	 * Algorithm for determining collation information
+	 * This method will check if it is dealing with character string datatypes.
 	 * If yes, then it will check if all the character string datatypes have
 	 * the same collation derivation and collation type associated with them.
 	 * If not, then the resultant DTD from this method will have collation
@@ -151,7 +155,7 @@
 	 * 
 	 * eg consider we are dealing with a database with territory based 
 	 * collation. Now consider following example first
-	 * sysCharColumn || userCharColumn
+	 * sysCharColumn1 || userCharColumn
 	 * The result of this concatenation will have collation derivation of NONE
 	 * because the first operand has collation derivation of IMPLICIT and 
 	 * collation type of UCS_BASIC whereas the 2nd opernad has collation 
@@ -166,6 +170,35 @@
 	 * resultant type will have collation derivation of IMPLICIT and collation 
 	 * type of UCS_BASIC
 	 * 
+	 * Note that this method calls DTD.getDominantType and that method returns
+	 * the dominant type of the 2 DTDs involved in this method. The method also
+	 * sets the collation info on the dominant type following the algorithm
+	 * mentioned in the comments of 
+	 * @see DataTypeDescriptor#getDominantType(DataTypeDescriptor, ClassFactory)
+	 * But when there are more than 2 DTDs involved in this ValueNodeList, we
+	 * can't determine the collation info using only 2 DTDs at a time which is
+	 * what TD.getDominantType does. Consider following eg
+	 * sysCharColumn1 || userCharColumn || sysCharColumn2
+	 * If we let the DataTypeDescriptor.getDominantType determine the collation
+	 * of the eg above, then DataTypeDescriptor.getDominantType will first set 
+	 * collation derivation of NONE for the following. This intermediate DTD is 
+	 * tracked by dominantDTS 
+	 * sysCharColumn1 || userCharColumn
+	 * Next, DataTypeDescriptor.getDominantType gets called for the intermediate
+	 * DTD (dominantDTS) and sysCharColumn2
+	 * dominantDTS || sysCharColumn2
+	 * For these two DTDs, DataTypeDescriptor.getDominantType will set 
+	 * collation type of UCS_BASIC and collation derivation of IMPLICIT. So, the
+	 * result string of the sysCharColumn1 || userCharColumn || sysCharColumn2
+	 * will have collation type of UCS_BASIC and collation derivation of 
+	 * IMPLICIT, but that is not correct. The reason for this is 
+	 * DataTypeDescriptor.getDominantType deals with only 2 DTDs at a time. To
+	 * fix this problem, we basically ignore the collation type and derivation 
+	 * picked by DataTypeDescriptor.getDominantType. Instead we let 
+	 * getDominantTypeServices use the simple algorithm listed at the top of
+	 * this method's comments to determine the collation type and derivation for 
+	 * this ValueNodeList object.
+	 * 
 	 * @return DataTypeServices		The dominant DataTypeServices.
 	 *
 	 * @exception StandardException		Thrown on error
@@ -233,7 +266,7 @@
 				//NONE.
 				dominantDTS.setCollationDerivation(StringDataValue.COLLATION_DERIVATION_NONE);
 			}			
-			//if we didn't fine any collation mismatch, then resultant dominant
+			//if we didn't find any collation mismatch, then resultant dominant
 			//DTD already has the correct collation information on it and hence
 			//we don't need to do anything.
 		}



Mime
View raw message