[
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 SchemaDescriptor(SD).
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();
else
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: 10.3.0.0
> 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.
