db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2528) Set the correct collation type in SchemaDescriptor. The collation type will be UCS_BASIC for system schemas but it can be TERRITORY_BASED/UCS_BASIC for user schemas.
Date Thu, 05 Apr 2007 21:20:32 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487103

Mamta A. Satoor commented on DERBY-2528:

Here is what I am thinking of how to make the correct default collation type available in
DataDictionary(DD) will have two additional fields and two additional apis. The field names
will be 
int collationTypeOfSystemSchemas
int collationTypeOfUserSchemas
The apis associated with them would be 
public int getCollationTypeOfSystemSchemas() 
public int getCollationTypeOfUserSchemas()
DD in it's boot method will initialize collationTypeOfSystemSchemas to StringDataValue.COLLATION_TYPE_UCS_BASIC
In the same boot method, it will check the collation property supplied through optional JDBC
attribute COLLATION and set collationTypeOfUserSchemas to StringDataValue.COLLATION_TYPE_UCS_BASIC
 or StringDataValue.COLLATION_TYPE_TERRITORY_BASED. This covers the changes required in DD.
Now coming to SD. SD will have a new field
int collationType
It will have a new api called
public int getCollationType()
This new field will get initialized in SD's constructor. SD's constructor already gets DD
and isSystem passed to it. SD can use these 2 parameters to initialize collationType. The
additional code in SD's constructor would look something like this 
if (isSystem) //check if I am a system schema
   collationType = DD.getCollationTypeOfSystemSchemas();
   collationType = DD.getCollationTypeOfUserSchemas();

The reason I am having SD's constructor call DD to get the collation type rather than collationType
simply getting passed to SD's constructor is that the later approach would require us to change
all the places where a SD object is created and have them pass the additional collationType
parameter to it's constructor. I searched through the code and there are several places where
we create a SD. 
With my approach, we have to change code in only one place and that would be in SD's constructor
(and ofcourse we need changes in DD as explained in my mail earlier. But the changes in DD
are required no matter how SD gets the right value in it's collationType field). 

> Set the correct collation type in SchemaDescriptor. The collation type will be UCS_BASIC
for system schemas but it can be TERRITORY_BASED/UCS_BASIC for user schemas.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-2528
>                 URL: https://issues.apache.org/jira/browse/DERBY-2528
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions:
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
> As per the wiki page http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478,
Section Collation Determination, item 2)
> )<column definition> (of character string type) SQL spec Section 11.1 <schema
definition>, General Rule 3 specifies that the character set associated with schema is
used as the default character set for all <column definitions>. Based on this, character
columns in user tables will have USER character set associated with them and hence collation
type of UCS_BASIC/TERRITORY_BASED. The collation derivation will be implicit. 
> In order for column definition to pick up the collation from the schema, correct collation
type should be available in schema. In Derby implementation world, this translates having
correct collation type in SchemaDescriptor. This jira entry is to track the work required
in associating collation type to a SchemaDescriptor.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message