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, 22 Mar 2007 14:18:33 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

------------------------------------------------------------------------------
  
  5)The type definition of a column is described by DTD (DataTypeDescriptor). This DTD will
have an additional attribute called collation type. The correct assoication of collation to
the DTD for system or user columns is easy and it will happen at bind time. But there are
other character expressions who are either string literals, or result of cast, trim, upper,
lower, substring, concatenate etc. Determining their collation type requires special handling.
  
- 5)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.
+ 6)For a string literal which is not inside an operation like upper/lower/substring etc,
it's collation type in DTD will be marked UNKNOWN. When such a string literal gets used in
a collation method, it's collation type will be same as the other operand involved in the
collation eg sysColumn1 < 'aaa', then the collation type of 'aaa' will change from UNKNOWN
to UCS_LOCALE at the comparison time. But if the comparison was userColumn1 < 'aaa', then
the collation type of 'aaa' will be that of the collaiton type of userColumn1. As a third
case, if the comparison was between 2 string literals, ie 'aaa' < 'bbb', then the collation
type of each of the string literal will be the COLLATION applicable at the user character
level.
  
- 6)For both a newly created 10.3 database and an upgraded 10.3 database, make sure that the
scale for character datatypes continue to be 0 (rather than the collation type value) through
the metadata. The overloading of scale in TypeDescriptor as collation for character datatypes
should be transparent to the end user. We should include test for the scale of character datatype.
+ 7)As for the character expressions involving CAST, TRIM, UPPER, LOWER, SUBSTRING, CONCATENATE,
the result character datatype will have the same collation type as their operands. 
  
- 7)Currently, store uses Monitor to create DVD template rows. The logic of creating DVDs
using formatids should be factored out from Monitor into DataValueFactory. 
+ 8)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.
  
- 8)This item is related to item 7. With Derby 10.3, collation type will be the additional
metadata in store for each column. When store will call DataValueFactory to create DVD template
row, it will pass the formatids and the collation types. DVF will need to be able to assoicate
the correct Collator with the DVD for Char datatypes depending on the collation type. And
in order to find the correct Collator, DVF needs to know the locale of the database. This
locale information will be set on DVF using a new method on DVF called void setLocale(Locale).
This call will be made by BasicDatabase after DVF has finished booting and before store starts
booting.
+ 9)For both a newly created 10.3 database and an upgraded 10.3 database, make sure that the
scale for character datatypes continue to be 0 (rather than the collation type value) through
the metadata. The overloading of scale in TypeDescriptor as collation for character datatypes
should be transparent to the end user. We should include test for the scale of character datatype.
  
- 9)Override all the collation related methods in the CollatorSQLChar. CollatorSQLChar is
a subclass of SQLChar.
+ 10)Currently, store uses Monitor to create DVD template rows. The logic of creating DVDs
using formatids should be factored out from Monitor into DataValueFactory. 
  
- 10)Add subclasses for SQLVarchar, SQLLongvarchar, SQLClob. These subclasses will override
the collation related methods in their superclasses.
+ 11)This item is related to item 7. With Derby 10.3, collation type will be the additional
metadata in store for each column. When store will call DataValueFactory to create DVD template
row, it will pass the formatids and the collation types. DVF will need to be able to assoicate
the correct Collator with the DVD for Char datatypes depending on the collation type. And
in order to find the correct Collator, DVF needs to know the locale of the database. This
locale information will be set on DVF using a new method on DVF called void setLocale(Locale).
This call will be made by BasicDatabase after DVF has finished booting and before store starts
booting.
  
- 11)CollatorSQLChar has a method called getCollationElementsForString which currently gets
called by like method. getCollationElementsForString gets the collation elements for the value
of CollatorSQLChar class. But say like method is looking for pattern 'A%' and the value of
CollatorSQLChar is 'BXXXXXXXXXXXXXXXXXXXXXXX'. This is eg of one case where it would have
been better to get collation element one character of CollatorSQLChar value at a time so we
don't go through the process of getting collation elements for the entire string when we don't
really need. This is a performance issue and could be taken up at the end of the implementation.
Comments on this from Dan and Dag can be found in DERBY-2416. 
+ 12)Override all the collation related methods in the CollatorSQLChar. CollatorSQLChar is
a subclass of SQLChar.
  
+ 13)Add subclasses for SQLVarchar, SQLLongvarchar, SQLClob. These subclasses will override
the collation related methods in their superclasses.
+ 
+ 14)CollatorSQLChar has a method called getCollationElementsForString which currently gets
called by like method. getCollationElementsForString gets the collation elements for the value
of CollatorSQLChar class. But say like method is looking for pattern 'A%' and the value of
CollatorSQLChar is 'BXXXXXXXXXXXXXXXXXXXXXXX'. This is eg of one case where it would have
been better to get collation element one character of CollatorSQLChar value at a time so we
don't go through the process of getting collation elements for the entire string when we don't
really need. This is a performance issue and could be taken up at the end of the implementation.
Comments on this from Dan and Dag can be found in DERBY-2416. 
+ 
- 12)Add tests for this feature. This a broad umbrella task but I do want to mention 2 specific
tests that we should be testing
+ 15)Add tests for this feature. This a broad umbrella task but I do want to mention 2 specific
tests that we should be testing
  a)Make sure the scale of the character datatypes is always 0 and it didn't get impacted
negatively by the overloading of scale field as collation type in TypeDescriptor.
  b)Test case for recovery - have an outstanding transaction with insert/delete/updates that
affect one or more character indexes (all with a collation setting that is different from
default collation). Make sure those log records get to the log and then crash the server.
Restarting the server will then run through the recovery code and will ensure that we test
for correct collation usage at recovery time. Mike has put more info about this in DERBY-2336.
  

Mime
View raw message