You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by ma...@apache.org on 2007/04/04 20:17:58 UTC
svn commit: r525568 - in /db/derby/code/trunk/java/engine/org/apache/derby:
catalog/TypeDescriptor.java catalog/types/TypeDescriptorImpl.java
iapi/types/DataTypeDescriptor.java
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" -