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 Thu, 05 Apr 2007 06:51:49 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 ==
  '''[[GetText(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. 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".
+ 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.
  
- 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.
+ 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. 
  
- 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.
+ 3)At compile time, make sure that the correct character class (ex SQLChar vs CollatorSQLChar)
is generated so at run time, we do not need to check what kind of Collator object need to
be used for character types. It should be all handled correctly at the code generation time
and the appropriate runtime methods (ex like method in SQLChar vs like method in WorkHorseForCollatorDatatypes)
should get called. This is the biggest unknown to me at this point and I need to do more research.
Will appreicate very much if someone has some thoughts on this.
  
- 4)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. 
- 
- 5)At compile time, make sure that the correct character class (ex SQLChar vs CollatorSQLChar)
is generated so at run time, we do not need to check what kind of Collator object need to
be used for character types. It should be all handled correctly at the code generation time
and the appropriate runtime methods (ex like method in SQLChar vs like method in WorkHorseForCollatorDatatypes)
should get called. This is the biggest unknown to me at this point and I need to do more research.
Will appreicate very much if someone has some thoughts on this.
- 
- 6)Store needs a way to determine the collation type for a given DVD. This collation type
will then be saved in the column metadata. Provide the api on DVD to return the correct collation
type.
+ 4)Store needs a way to determine the collation type for a given DVD. This collation type
will then be saved in the column metadata. Provide the api on DVD to return the correct collation
type.
  
  '''[[GetText(Question)]]''' Will there be an api like DVD.getCollationType()?
  
- 7)BasicDatabase needs to set the Locale value in the DVF after DVF has booted. Probably
with an api like DVF.setLocale(Locale). DVF will use this Locale object to construct the correct
Collator in case user has requested territory based collation through jdbc url at database
create time.
+ 5)BasicDatabase needs to set the Locale value in the DVF after DVF has booted. Probably
with an api like DVF.setLocale(Locale). DVF will use this Locale object to construct the correct
Collator in case user has requested territory based collation through jdbc url at database
create time.
  
  '''[[GetText(Store changes)]]'''
  
@@ -136, +132 @@

  
  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.
+ 
+ 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.
+ 
  '''[[GetText(Boot time)]]'''
  
  1)At the time of database create time, optional JDBC url attribute COLLATION is validated
by the boot code in data dictionary and the validated value of COLLATION(if none specified
by user, then it will default to UCS_BASIC which is also the only collation available on pre-10.3
databases) attribute is saved as derby.database.collation property in the properties conglomerate.
This work was done by revision 511283

Mime
View raw message