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 07:21:45 -0000
Message-ID: <20070405072145.16464.51921@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

------------------------------------------------------------------------------
  == Collation Determination ==
  In Derby 10.3, there will be two character sets associated with the database. These 2 character sets will have identical character repertoire(UCS) but they may have different collation associated with them depending on the value of JDBC url attribute COLLATION. The 2 character sets will be 
  
- 1)USER character set - collation of UCS_BASIC/TERRITORY_BASED depending on the value of jdbc url attribute COLLATION specified at create database time.
+ a)USER character set - collation of UCS_BASIC/TERRITORY_BASED depending on the value of jdbc url attribute COLLATION specified at create database time.
  
- 2)SQL_IDENTIFIER character set - collation of UCS_BASIC.
+ b)SQL_IDENTIFIER character set - collation of UCS_BASIC.
  
  As per SQL spec, Section 11.1<schema definition>, there is an optional syntax to associate a character set for a schema at create schema time. Syntax Rule 5 says that if a character set is not specified by the user, then the character set associated with schema is implementation defined. In Derby 10.3, system schemas will be associated with SQL_IDENTIFER character set and all the user schemas will be associated with USER character set. Futher on, General Rule 3 specifies that the character set associated with schema is used as the default character set for all <column definitions>. Based on this, all the user character columns will pick up the collation associated with USER character set and all the system character columns will pick the up the collation associated with SQL_IDENTIFIER character set. 
   
@@ -30, +30 @@

  
  Some other background information on collation derivation and collation type from SQL spec : 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 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 this release). 
+ a)Collation derivation will be explicit if 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 this 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. 
+ b)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). 
+ c)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). 
  
  Following lists the collation type association for various occurences of character string types and for operations involving character string types in Derby 10.3
  
@@ -65, +65 @@

  == Outstanding items ==
  '''[[GetText(Language changes)]]'''
  
- 1)When a character column is added using CREATE TABLE/ALTER TABLE, make sure that the correct collate type is populated in the TypeDescriptor's scale field in the SYS.SYSCOLUMNS table.
+ 1)When a character column is added using CREATE TABLE/ALTER TABLE, make sure that the correct collate type is populated in the TypeDescriptor's scale field in the SYS.SYSCOLUMNS table. In order to do this, CREATE TABLE/ALTER TABLE need to get their schema descriptor's collation type. The collation type of the schema descriptor will decide the collation type of the character columns defined in CREATE TABLE/ALTER TABLE. This comes from item 2 under Collation Determination section on this page. The first step in implementing CREATE TABLE/ALTER TABLE is to have the correct collation type available at SchemaDescriptor level.
  
  2)WorkHorseForCollatorDatatypes should override all the collation related methods so that it uses the non-default Collator. All the non-default-collation-sensitive classes have an instance of WorkHorseForCollatorDatatypes which is used to call the collation related methods. This ensures that these collation related methods are implemented in one central place rather than in all the collation-sensitive classes.