db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by MamtaSatoor
Date Mon, 02 Apr 2007 19:49:55 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by MamtaSatoor:
http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478

------------------------------------------------------------------------------
  == Outstanding items ==
  Language changes
  
- 1)The type definition of a data type is described by DTD (DataTypeDescriptor). This DTD
will have two additional attributes called collation type and collation derivation. As per
SQL spec, the collation derivation can hold 3 values, "explicit", "implicit" and "none". In
Derby 10.3, the collation derivation will never be "explicit" because Derby 10.3 does not
support SQL Standard's COLLATE clause. In Derby 10.3, the collation derivation can be "implicit"
or "none". If collation derivation is "none", then it means the collation type can't be determined.
This can happen when an aggregate function is working with operands of different collation
types. If the result of such an aggregate function is character string type, then it's collation
derivation will be "none", ie it can not be determined. Other than this aggregate "none" case,
the collation derivation will always be "implicit" and collation type will be UCS_BASIC/TERRITORY_BASED.
Which one of the 2 collation types is pick
 ed for a character string type is explained in detail in section "Collation Determination".
+ 1)The type definition of a data type is described by DTD (DataTypeDescriptor). This DTD
will have two additional attributes called collation type and collation derivation. (These
new attributes only apply to collation sensitive types, namely char datatypes. For other data
types, these attributes will be ignored.) As per SQL spec, the collation derivation can hold
3 values, "explicit", "implicit" and "none". In Derby 10.3, the collation derivation will
never be "explicit" because Derby 10.3 does not support SQL Standard's COLLATE clause. In
Derby 10.3, the collation derivation can be "implicit" or "none". If collation derivation
is "none", then it means the collation type can't be determined. This can happen when an aggregate
function is working with operands of different collation types. If the result of such an aggregate
function is character string type, then it's collation derivation will be "none", ie it can
not be determined. Other than this aggregate "none" case, the 
 collation derivation will always be "implicit" and collation type will be UCS_BASIC/TERRITORY_BASED.
Which one of the 2 collation types is picked for a character string type is explained in detail
in section "Collation Determination".
  
  2)The TypeDescriptor for character columns always has 0 for scale because scale does not
apply to character datatypes. Starting Derby 10.3, this scale field in TypeDescriptor will
be overloaded to indicate the collate type of the character. So, if user has requested for
TERRITORY_BASED collation, then the scale in TypeDescriptor for user columns(character) will
be 1(TERRITORY_BASED). The scale will be always 0(UCS_BASIC) for SYS schema character columns
and for databases with collation set to UCS_BASIC. These changes will go in readExternal and
writeExternal methods of TypeDescriptor. Using the value 0 for UCS_BASIC will ensure that
pre-10.3 databases with scale field as 0 in TypeDescriptor will continue to use UCS_BASIC
after upgrade to 10.3, because 0 in scale field corresponds to UCS_BASIC collation type.
  
@@ -110, +110 @@

  1)CollatorSQLChar has a method called getCollationElementsForString which currently gets
called by like method. getCollationElementsForString gets the collation elements for the value
of CollatorSQLChar class. But say like method is looking for pattern 'A%' and the value of
CollatorSQLChar is 'BXXXXXXXXXXXXXXXXXXXXXXX'. This is eg of one case where it would have
been better to get collation element one character of CollatorSQLChar value at a time so we
don't go through the process of getting collation elements for the entire string when we don't
really need. This is a performance issue and could be taken up at the end of the implementation.
Comments on this from Dan and Dag can be found in DERBY-2416. 
  
  Miscellaneous item
+ 
  1)Make sure the space padding at the end of various character datatypes is implemented commented
correctly in javadocs. This padding is used in collation related methods. For eg check SQLChar.stringCompare
method.
  
  == Implemented items ==

Mime
View raw message