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 05:57:25 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:

  12)And last but not least, the collation methods will follow the rules defined by SQL spec
in Section 9.13 Collation determination Syntax Rules 2 and 3e. In other words, at least one
operand shall have a declared type collation (that means if the comparison is sysChar1|userChar1
> sysChar2|userChar2, then such a comparison will fail because both sides of > operator
have collation derivation of none after applying the rules of 10 above) AND every operand
whose collation derivation is implicit shall have the same declared type collation (that means
if the comparison is sysChar1 > userChar1WithTerritoryBasedCollation, then such a comparison
will fail because left operand has collation derivation as implicit and collation type as
UCS_BASIC and the right operand has collation derivation implicit and collation type as TERRITORY_BASED)

  == Outstanding items ==
- Language changes
+ '''[[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".
@@ -81, +81 @@

  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.
- Store changes
+ '''[[GetText(Store changes)]]'''
  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 soft upgraded
to 10.3, 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. For any conglomerate created in a 10.3 new database or a 10.3 hard
@@ -95, +95 @@

  5)Check if any code needs to go in for sorter. Not sure if this falls under Language or
Store section. Mike pointed out that Derby has some template code specific to sorter.
- Testing
+ '''[[GetText(Testing)]]'''
  1)Add tests for this feature. This a broad umbrella task but I do want to mention 3 specific
tests that we should be testing
@@ -113, +113 @@

  g)Add tests for sorts that can fit in memory and the sorts that have to spill over to disk.
It will be good to make sure that correction collation get used for them.
- Metadata query changes
+ '''[[GetText(Metadata query changes)]]'''
  1)Fix the metadata queries so that string literals can be compared with character columns
from system schema. String literals will have the USER character set associated with them
and system character columns will have SQL_IDENTIFIER associated with them. In order to compare
them, both the sides of the comparison should come from same character set. Following casting
of string literal will achieve that. syscharcol = CAST(string_literal as varchar(128)). 
- Network Server
+ '''[[GetText(Network Server)]]'''
  1)At this point, I am not sure what kind of work (if any) will be involved for Network Server.
- Performance items
+ '''[[GetText(Performance/Desirable items)]]'''
  1)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. 
- Miscellaneous item
+ 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-
+ '''[[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
  == Implemented items ==
- Type system
+ '''[[GetText(Type system)]]'''
  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.
- Boot time
+ '''[[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
  == Related Pages ==

View raw message