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: Mon, 02 Apr 2007 19:10:41 -0000
Message-ID: <20070402191041.2416.22953@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)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 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. 
+ 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 gon in readExternal and writeExternal methods of TypeDescriptor.
  
  3)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.
  
@@ -79, +79 @@

  
  Store changes
  
- 1)Store column level metadata for collate in Store. Store keeps a version number that describes the strucutre of column level metadata. For existing pre-10.3 databases which get upgraded to 10.3 and for new 10.3 databases with default collatoin(UCS_BASIC), the structure of column level metadata will remain same as 10.2 structure of column level metadata, ie they will not include collate information in their store metadata. A new version would be used in Store for structure of column level metadata if the newly created 10.3 database has asked for territory based collation. In other words, information about collate will be kept in Store column level metadata only if we are working with a 10.3 newly created database with territory based collation. This approach will make sure that we do not have to do an on-disk store metadata upgrade when upgrading a pre-10.3 database to 10.3 version.
+ 1)Store column level metadata for collate in Store. Store keeps a version number that describes the structure of column level metadata. For existing pre-10.3 databases which get upgraded to 10.3 and for new 10.3 databases with default collatoin(UCS_BASIC), the structure of column level metadata will remain same as 10.2 structure of column level metadata, ie they will not include collate information in their store metadata. A new version would be used in Store for structure of column level metadata if the newly created 10.3 database has asked for territory based collation. In other words, information about collate will be kept in Store column level metadata only if we are working with a 10.3 newly created database with territory based collation. This approach will make sure that we do not have to do an on-disk store metadata upgrade when upgrading a pre-10.3 database to 10.3 version.
  
  2)Currently, store uses Monitor to create DVD template rows. The logic of creating DVDs using formatids should be factored out from Monitor into DataValueFactory. Talking in terms of code, RowUtil.newClassInfoTemplate should call DVF.classFromIdentifier rather than Monitor.classFromIdentifier.