Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: derby-commits@db.apache.org
Date: Thu, 05 Apr 2007 21:23:54 -0000
Message-ID: <20070405212354.20564.13576@eos.apache.org>
Subject: [Db-derby Wiki] Update of "BuiltInLanguageBasedOrderingDERBY-1478" by
 MamtaSatoor

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

------------------------------------------------------------------------------
  
  1)Subclasses with non-default-collation have been implemented for character types SQLChar, SQLVarchar, SQLLongvarchar and SQLClob. The new subcalsses are called CollatorSQLChar, CollatorSQLVarchar, CollatorSQLLongvarchar and CollatorSQLClob, respectively. They reside in derby.iapi.types package. This work was done by revisions 516864, 516869 and 518479, 524545.
  
- 2)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. DTD probably will need getter and setter for the 2 additional attributes.(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 (0)UCS_BASIC/(1)TERRITORY_BASED. Which one of the 2 collation types is picked for a character string type is explained in detail in section "Collation Determination". This work was done by revisions 525568 and 525729.
+ 2)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. DTD probably will need getter and setter for the 2 additional attributes.(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 (0)UCS_BASIC/(1)TERRITORY_BASED. Which one of the 2 collation types is picked for a character string type is explained in detail in section "Collation Determination". This work was done by revisions 525568 and 525729. The work for this line item went in as part Jira entry DERBY-2524.
  
- 3)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. This work was done by revisions 525568 and 525729.
+ 3)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. This work was done by revisions 525568 and 525729. The work for this line item went in as part Jira entry DERBY-2524.
  
  '''[[GetText(Boot time)]]'''