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 23:21:53 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

------------------------------------------------------------------------------
  
  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.
  
+ h)Add tests to set the collation attribute on the jbdc url and testing it later with VALUES
SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.database.collation') Some possible tests are
+ 
+ i)connect 'jdbc:derby:c:/dellater/db1;create=true;territory=it'; //no collaiton attribute
but is should get set to UCS_BASIC.
+ 
+ ii)connect 'jdbc:derby:c:/dellater/db1;create=true;territory=it;collation=UCS_BASIC';
+ 
+ iii)connect 'jdbc:derby:c:/dellater/db1;create=true;territory=it;collation=TERRITORY_BASED';
+ 
+ iv)connect 'jdbc:derby:c:/dellater/db1;create=true;territory=it;collation=CUSTOM_COLLATION';
//invalid value for collation attribute
+ 
+ v)connect 'jdbc:derby:c:/dellater/db1;create=true;territory=it;collation=TERRITORY_BASED;collation=TERRITORY_BASED';//give
same value twice
+ 
+ vi)connect 'jdbc:derby:c:/dellater/db1;create=true;territory=it;collation=TERRITORY_BASED;collation=UCS_BASIC';//give
2 different values. The last value should get picked
+ 
+ vii)connect 'jdbc:derby:c:/dellater/db1;create=true;territory=it;collation=UCS_BASIC;collation=TERRITORY_BASED';//same
as vi but valid values in different order
+ 
+ viii)After database create time, try to give collation attribute again. It should get quitely
ignored.
+ connect 'jdbc:derby:c:/dellater/db1;create=true;territory=it;collation=TERRITORY_BASED';
+ connect 'jdbc:derby:c:/dellater/db1;collation=UCS_BASIC';
+ 
+ ix)connect 'jdbc:derby:c:/dellater/db1;create=true;collation=TERRITORY_BASED';//give collation
attribute w/o the locale attribute. We might need to discuss this to decide what happens.
Will put it under outstanding items.
+ 
+ x)Connect to a pre-10.3 database in soft upgrade mode
+ connect 'jdbc:derby:c:/dellater/db102';
+ 
+ xi)Upgrade a pre-10.3 database
+ connect 'jdbc:derby:c:/dellater/db102;upgrade=true';
+ 
+ 
  '''[[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)). 
@@ -123, +152 @@

  
  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.
+ 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)]]'''
  

Mime
View raw message