[jira] Updated: (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.

["Mamta A. Satoor (JIRA)" <ji...@apache.org>]

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

Mamta A. Satoor updated DERBY-2528:
-----------------------------------

    Attachment: DERBY2528_Collation_Type_In_Schema_v1_diff.txt
                DERBY2528_Collation_Type_In_Schema_v1_stat.txt

I have a patch ready to commit (after the tests finish running) based on the logic in the earlier comment to this Jira entry. The patch is attached to this Jira entry as DERBY2528_Collation_Type_In_Schema_v1_diff.txt

svn stat -q
M      java\engine\org\apache\derby\impl\sql\catalog\DataDictionaryImpl.java
M      java\engine\org\apache\derby\iapi\sql\dictionary\SchemaDescriptor.java
M      java\engine\org\apache\derby\iapi\sql\dictionary\DataDictionary.java

The patch description is as follows
1)The changes in DataDictionary(DD) involves adding 2 new apis. These apis is how a SchemaDescriptor in it's constructor will get the correct collation type from DD. The 2 apis are as follows
public int getCollationTypeOfSystemSchemas();
public int getCollationTypeOfUserSchemas();
2)The changes in DataDictionaryImpl(DDimpl) involves adding 2 new fields and implementation of the apis added in DD. The 2 new fields are 
private int collationTypeOfUserSchemas;
private int collationTypeOfSystemSchemas;
These 2 fields get initialized in DDimpl's boot method. Since the primary purpose of these 2 fields is to have correct collation type for user and system schema so a SchemaDescriptor(SD)'s constructor can call the apis on these 2 fields, these 2 fields should get initialized before SDs start loading into the system. 
It is easy to set collationTypeOfUserSchemas because in Derby 10.3, it is always UCS_BASIC. I do this initalization before DDimpl's boot method calls getBuiltinSchemas. This method was used to load SYS SDs along with SESSION SD(which is used for global temporary tables. But global temporary tables are user defined temporary tables and hence SESSION schema should be considered a user schema rather than system schema. But the collation type of user schemas can't be determined at this point in the boot method and hence for this reason, 
I have taken out SESSION SD creation out of getBuiltinSchemas. Later, in DDimpl's boot method, I go through the code of looking at COLLATION property(for existing database)/attribute (for database that is getting created) to determine the user schema collation. Once that is determined, we are safe to load a SD for SESSION schema.
3)The change in SD is to have a field called collationType and this field gets initialized in SD's constructor using the 2 new apis on DD.

I will let the tests run to completion and if no new failures, then I will commit this patch after that.

If anyone has any feedback on this implementation, please let me know.


> 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
>         Attachments: DERBY2528_Collation_Type_In_Schema_v1_diff.txt, DERBY2528_Collation_Type_In_Schema_v1_stat.txt
>
>
> 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.