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 Fri, 06 Apr 2007 18:48:59 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)Set the correct collation type in SchemaDescriptor. On this page, Section Collation Determination,
item 2) says that column definitions pick up their collation from the schema that they are
defined in. In order for that to happen, schema should have the right collaiton type associated
with it. This work of attaching right collation type to a schema will happen in DERBY-2528.
+ 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. 
  
- 2)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 and that will get done in line
item 1 under Outstanding items section.
+ 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)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)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)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.
- 
- 5)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()?
  
- 6)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)]]'''
  
@@ -125, +123 @@

  
  2)TypeDescriptorImpl's readExternal and writeExternal methods currently save only collation
type of a character string type column in SYSCOLUMNS's COLUMNDATATYPE column. Collation derivation
of character string type column does not get saved anywhere. In this release of Derby, collation
derivation of these persistent character string type columns is always "implicit" and hence
it is safe even if we don't save the collation derivation anywhere. In readExternal method,
we can always initialize the collation derivation to be "implicit" for character string type
columns. But in some future release of Derby, it might be possible to define an explicit collation
type for a column using SQL's COLLATE clause. In such a case, the collation derivation of
persistent column's won't be implicit, rather it will be explicit. In order to support that,
may be we should consider saving the collation derivation starting Derby 10.3 itself. Look
at thread http://www.nabble.com/-jira--Created%3A-
 %28DERBY-2524%29-DataTypeDescriptor%28DTD%29-needs-to-have-collation-type-and-collation-derivation.-These-new-fields-will-apply-only-for-character-string-types.-Other-types-should-ignore-them.-p9842379.html
  
+ 3)Set the correct collation type in SchemaDescriptor. On this page, Section Collation Determination,
item 2) says that column definitions pick up their collation from the schema that they are
defined in. In order for that to happen, schema should have the right collaiton type associated
with it. This work of attaching right collation type to a schema went in as part of DERBY-2528
with revision 526243 and 526237.
+ 
  '''[[GetText(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.

Mime
View raw message