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 Mon, 09 Apr 2007 08:00:34 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

The comment on the change is:
Accidentally had put SchemaDescriptor changes under the wrong list on this wiki.

------------------------------------------------------------------------------
  
  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 526237, 526243 and 526313.
- 
  '''[[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.
@@ -169, +167 @@

  
  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. The
work for this line item went in as part Jira entry DERBY-2524.
  
+ '''[[GetText(Data Dictionary)]]'''
+ 
+ 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 went in as part of DERBY-2528
with revision 526237, 526243 and 526313.
+ 
+ 
  '''[[GetText(System catalog)]]'''
  
  1)The TypeDescriptor for a character column 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. The work for this line item went in as part
Jira entry DERBY-2524.

Mime
View raw message