db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ma...@apache.org
Subject svn commit: r525568 - in /db/derby/code/trunk/java/engine/org/apache/derby: catalog/TypeDescriptor.java catalog/types/TypeDescriptorImpl.java iapi/types/DataTypeDescriptor.java
Date Wed, 04 Apr 2007 18:17:58 GMT
Author: mamta
Date: Wed Apr  4 11:17:57 2007
New Revision: 525568

URL: http://svn.apache.org/viewvc?view=rev&rev=525568
Log:
This patch is for DERBY-2524 (DataTypeDescriptor(DTD) needs to have collation type and collation
derivation. These new fields will apply 
only for character string types. Other types should ignore them.) and it does following 2
things
1)Add collation type and collation derivation attributes and apis to TypeDescriptor interface
and it's implementations.
2)Save the collation type in the scale field of character types in writeExternal method of
TypeDescriptorImpl. And read the scale field into 
the collation type for character types in readExternal method of TypeDescriptorImpl. 

svn stat -q
M      java\engine\org\apache\derby\iapi\types\DataTypeDescriptor.java
M      java\engine\org\apache\derby\catalog\TypeDescriptor.java
M      java\engine\org\apache\derby\catalog\types\TypeDescriptorImpl.java

Details of the patch
1)Added getters and setters for collationType and collationDerivation in TypeDescriptor. In
addition, TypeDescriptor has new constants
defined in them which will be used by the rest of the collation related code in Derby. One
of the constants is COLLATION_DERIVATION_INCORRECT
I am initializing the collation derivation for all the data types to COLLATION_DERIVATION_INCORRECT
in TypeDescriptorImpl. This should get 
changed to "implicit" or "none" for character string types before the runtime code kicks in.
For all the other types, it will remain set to
COLLATION_DERIVATION_INCORRECT because collation does not apply to those data types.
2)DTD implements the new apis in the TypeDescriptor interface.
3)2 set of changes went into 
a)TypeDescriptorImpl has 2 new fields, namely, collationType and collationDerivation. collationDerivation
is initialized to 
TypeDescriptor.COLLATION_DERIVATION_INCORRECT. For character string types, these field should
get set correctly. In addition, there are apis 
to set and get values out of these 2 fields.
b)The next change for this class is in writeExternal and readExternal methods. I would like
community's feedback on my assumption for this
particular change. The collation type of a character string type will get saved in the existing
scale field since scale does not apply to 
character string types. My question is about collation derivation. The collation derivation
infromation does not get saved like collation 
type. But may be that is ok because I am assuming that writeExternal and readExternal get
called only for the persistent columns (ie columns 
belonging to system and user tables). Collation derivation of such character string columns
(coming from persistent tables) is always 
implicit. And, hence in readExternal, for character string types, I can initialize collation
derivation to be implicit. My assumption is 
that readExternal and writeExternal methods will never get called for character string types
with collation of none or explicit. Today we 
don't have explicit as one of the possible values for collation derivation, but a character
string type will have the collation derivation 
of none if it was the result of an aggregate method involving operands with different collation
derivations. This comes from item 11) from 
Section Collation Determination section at http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478

Questions
1)I have included all the constant definitions related to collation in TypeDescriptor. If
anyone has suggestion on a better place to 
define them, let me know. Wonder if there is already a class to define miscellaneous constant
definitions like the ones I have added. 
TypeDescriptor does look like a good place for these constants defined by me because these
constants all belong to the data type world.
2)Is it right to assume that readExternal and writeExternal methods in TypeDescriptorImpl
will get called only for persistent columns?


Modified:
    db/derby/code/trunk/java/engine/org/apache/derby/catalog/TypeDescriptor.java
    db/derby/code/trunk/java/engine/org/apache/derby/catalog/types/TypeDescriptorImpl.java
    db/derby/code/trunk/java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java

Modified: db/derby/code/trunk/java/engine/org/apache/derby/catalog/TypeDescriptor.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/catalog/TypeDescriptor.java?view=diff&rev=525568&r1=525567&r2=525568
==============================================================================
--- db/derby/code/trunk/java/engine/org/apache/derby/catalog/TypeDescriptor.java (original)
+++ db/derby/code/trunk/java/engine/org/apache/derby/catalog/TypeDescriptor.java Wed Apr 
4 11:17:57 2007
@@ -46,6 +46,31 @@
 
 	public	static	int MAXIMUM_WIDTH_UNKNOWN = -1;
 
+	/**
+	  For a character string type, the collation derivation should always be 
+	  "explicit"(not possible in Derby 10.3), "implicit" or "none". We will 
+	  start by setting it to "error" here. But at runtime, no TypeDescriptor 
+	  which belongs to a character string type should ever have a collation 
+	  derivation of "error". The initialization to "error" is for catching an 
+	  edge(bug) case where the collation derivation may not have gotten set 
+	  correctly for a character string type.
+	  For all the other types (which are not character string types, the 
+	  collation derivation will be set to "error".
+	 */
+	public	static	String COLLATION_DERIVATION_INCORRECT = "error";
+	public	static	String COLLATION_DERIVATION_IMPLICIT = "implicit";
+	public	static	String COLLATION_DERIVATION_NONE = "none";
+	/**
+	 * In Derby 10.3, all the character columns could have a collation type of
+	 * UCS_BASIC. This is same as what we do in Derby 10.3 release. The other
+	 * option in Derby 10.3 is that all the character string types belonging to
+	 * system tables will collate using UCS_BASIC but all the character string
+	 * types belonging to user tables will collate using TERRITORY_BASED
+	 * collation.
+	 */
+	public	static	int COLLATION_VALUE_UCS_BASIC = 0;
+	public	static	int COLLATION_VALUE_TERRITORY_BASED = 1;
+
 
 	///////////////////////////////////////////////////////////////////////
 	//
@@ -139,6 +164,71 @@
 	 
 	 */
 	public 	String		getSQLstring();
+
+	/**
+	 * Get the collation type for this type. This api applies only to character
+	 * string types. And it's return value is valid only if the collation 
+	 * derivation  of this type is "implicit" or "explicit". (In Derby 10.3,
+	 * collation derivation can't be "explicit". Hence in Derby 10.3, this api
+	 * should be used only if the collation derivation is "implicit". 
+	 *
+	 * @return	collation type which applies to character string types with
+	 * collation derivation of "implicit" or "explicit". The possible return
+	 * values in Derby 10.3 will be 0(UCS_BASIC) and 1(TERRITORY_BASED). 
+	 * 
+	 */
+	public int getCollationType();
+
+	/**
+	 * Set the collation type of this DTD
+	 * @param collationDerivationValue This will be UCS_BASIC/TERRITORY_BASED
+	 */
+	public void setCollationType(int collationTypeValue);
+
+	/**
+	 * Get the collation derivation for this type. This applies only for
+	 * character string types. For the other types, this api should be
+	 * ignored.
+	 * 
+	 * SQL spec talks about character string types having collation type and 
+	 * collation derivation associated with them (SQL spec Section 4.2.2 
+	 * Comparison of character strings). If collation derivation says explicit 
+	 * or implicit, then it means that there is a valid collation type 
+	 * associated with the charcter string type. If the collation derivation is 
+	 * none, then it means that collation type can't be established for the 
+	 * character string type.
+	 * 
+	 * 1)Collation derivation will be explicit if SQL COLLATE clause has been  
+	 * used for character string type (this is not a possibility for Derby 10.3 
+	 * because we are not planning to support SQL COLLATE clause in the 10.3
+	 * release). 
+	 * 
+	 * 2)Collation derivation will be implicit if the collation can be 
+	 * determined w/o the COLLATE clause eg CREATE TABLE t1(c11 char(4)) then 
+	 * c11 will have collation of USER character set. Another eg, TRIM(c11) 
+	 * then the result character string of TRIM operation will have collation 
+	 * of the operand, c11.
+	 * 
+	 * 3)Collation derivation will be none if the aggregate methods are dealing 
+	 * with character strings with different collations (Section 9.3 Data types 
+	 * of results of aggregations Syntax Rule 3aii).
+	 *  
+	 * Collation derivation will be initialized to "error" but by the 
+	 * time the runtime code kicks in, it should get set to "implicit"
+	 * or "none". Otherwise, we have run into a bug.
+	 *  
+	 * @return Should be "implicit" or "none". A value of "error" indicates 
+	 * that the collation derivation of character type has not been set
+	 * correctly.
+	 */
+	public String getCollationDerivation();
+
+	/**
+	 * Set the collation derivation of this DTD
+	 * @param collationDerivationValue This will be implicit/none/explicit
+	 * In Derby 10.3, we do not expect to get value explicit.
+	 */
+	public void setCollationDerivation(String collationDerivationValue);
 
 }
 

Modified: db/derby/code/trunk/java/engine/org/apache/derby/catalog/types/TypeDescriptorImpl.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/catalog/types/TypeDescriptorImpl.java?view=diff&rev=525568&r1=525567&r2=525568
==============================================================================
--- db/derby/code/trunk/java/engine/org/apache/derby/catalog/types/TypeDescriptorImpl.java
(original)
+++ db/derby/code/trunk/java/engine/org/apache/derby/catalog/types/TypeDescriptorImpl.java
Wed Apr  4 11:17:57 2007
@@ -52,6 +52,10 @@
 	private int						scale;
 	private boolean					isNullable;
 	private int						maximumWidth;
+	/** @see TypeDescriptor.getCollationType */
+	private int						collationType;
+	/** @see TypeDescriptor.getCollationDerivation() */
+	private String					collationDerivation = TypeDescriptor.COLLATION_DERIVATION_INCORRECT;
 
 	/**
 	 * Public niladic constructor. Needed for Formatable interface to work.
@@ -327,6 +331,30 @@
 		isNullable = nullable;
 	}
 
+	/** @see TypeDescriptor.getCollationType */
+	public int	getCollationType()
+	{
+		return collationType;
+	}
+
+	/** @see TypeDescriptor.setCollationType */
+	public void	setCollationType(int collationTypeValue)
+	{
+		collationType = collationTypeValue;
+	}
+
+	/** @see TypeDescriptor.getCollationDerivation */
+	public String	getCollationDerivation()
+	{
+		return collationDerivation;
+	}
+
+	/** @see TypeDescriptor.setCollationDerivation */
+	public void	setCollationDerivation(String collationDerivationValue)
+	{
+		collationDerivation = collationDerivationValue;
+	}
+
 	/**
 	 * Converts this data type descriptor (including length/precision)
 	 * to a string. E.g.
@@ -374,6 +402,8 @@
 		if(!this.getTypeName().equals(typeDescriptor.getTypeName()) ||
 		   this.precision != typeDescriptor.getPrecision() ||
 		   this.scale != typeDescriptor.getScale() ||
+		   this.collationDerivation.equals(typeDescriptor.getCollationDerivation()) ||
+		   this.collationType == typeDescriptor.getCollationType() || 
 		   this.isNullable != typeDescriptor.isNullable() ||
 		   this.maximumWidth != typeDescriptor.getMaximumWidth())
 		   return false;
@@ -396,7 +426,28 @@
 	{
 		typeId = (BaseTypeIdImpl) in.readObject();
 		precision = in.readInt();
-		scale = in.readInt();
+		
+		switch (typeId.getJDBCTypeId()) {
+		case Types.CHAR:
+		case Types.VARCHAR:
+		case Types.LONGVARCHAR:
+		case Types.CLOB:
+			scale = 0;
+			collationType = in.readInt();
+			//I am assuming that the readExternal gets called only on 
+			//persistent columns. Since all persistent character string type
+			//columns always have the collation derivation of implicit, I will 
+			//simply use that value for collation derivation here for character 
+			//string type columns.
+			collationDerivation = TypeDescriptor.COLLATION_DERIVATION_IMPLICIT;
+			break;
+		default:
+			scale = in.readInt();
+			collationType = 0;
+			collationDerivation = TypeDescriptor.COLLATION_DERIVATION_INCORRECT;
+			break;
+		}
+		
 		isNullable = in.readBoolean();
 		maximumWidth = in.readInt();
 	}
@@ -413,7 +464,19 @@
 	{
 		out.writeObject( typeId );
 		out.writeInt( precision );
-		out.writeInt( scale );
+
+		switch (typeId.getJDBCTypeId()) {
+		case Types.CHAR:
+		case Types.VARCHAR:
+		case Types.LONGVARCHAR:
+		case Types.CLOB:
+			out.writeInt( collationType );
+			break;
+		default:
+			out.writeInt( scale );
+			break;
+		}		
+		
 		out.writeBoolean( isNullable );
 		out.writeInt( maximumWidth );
 	}

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=525568&r1=525567&r2=525568
==============================================================================
--- 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 Wed
Apr  4 11:17:57 2007
@@ -777,6 +777,30 @@
 		return typeDescriptor.getScale();
 	}
 
+	/** @see TypeDescriptor.getCollationType */
+	public int	getCollationType()
+	{
+		return typeDescriptor.getCollationType();
+	}
+
+	/** @see TypeDescriptor.setCollationType */
+	public void	setCollationType(int collationTypeValue)
+	{
+		typeDescriptor.setCollationType(collationTypeValue);
+	}
+
+	/** @see TypeDescriptor.getCollationDerivation */
+	public String	getCollationDerivation()
+	{
+		return typeDescriptor.getCollationDerivation();
+	}
+
+	/** @see TypeDescriptor.setCollationDerivation */
+	public void	setCollationDerivation(String collationDerivationValue)
+	{
+		typeDescriptor.setCollationDerivation(collationDerivationValue);
+	}
+
 	/**
 	 * Returns TRUE if the datatype can contain NULL, FALSE if not.
 	 * JDBC supports a return value meaning "nullability unknown" -



Mime
View raw message