[
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.
