db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Thu, 15 Mar 2007 19:18:31 GMT


Daniel John Debrunner wrote:
> Mike Matrigali wrote:
> 
>>
>>
>> Mike Matrigali wrote:
>>
>>>
>>>
>>> Daniel John Debrunner wrote:
>>>
>>>> Mike Matrigali wrote:
>>>>
>>>>> I think I am missing/not understanding your direction.
>>>>>
>>>>> are there still 4 new types?
>>>>
>>>>
>>>>
>>>>
>>>> No, collation becomes an attribute of the existing character types 
>>>> just like length and nullability are.
>>
>> What is CollatorSQLChar in your proposal then?
> 
> 
> Same as in Mamta's current code.
> 
> CollatorSQLChar is a DataValueDescriptor, these are holders for values 
> of a type, they are not a type themselves. I think that's where the 
> confusion is coming in.
> 
> A type in Derby is composed of much more. The type definition of a 
> column is described by a DataTypeDescriptor, it is this class that would 
>  hold extra information (an int) to describe the collation type. Also 
> some changes for classes involved in type creation at compile time will 
> be needed, CharTypeCompiler at least.
> 
> A writeup of the roles of the type classes is in the package.html for 
> the types package.
> 
> http://db.apache.org/derby/javadoc/engine/org/apache/derby/iapi/types/package-summary.html#package_description

> 
> 
> So there would be four new classes that implement DataValueDescriptor, 
> for the Collator based collation of the four existing character types, 
> as Mamta has implicitly proposed. But there would not be four new 
> internal types and all the overhead it entails.

Thanks, this is what I was missing (I was using type when I meant 
class).  Overhead of collation will be avoided in the default by at 
compile time getting the code to the right CLASS. Current db's will
be directed to SQLChar which will not need know anything about 
collations, and collation created db's will get CollatorSQLChar instead
that will override as appropriate.

This seems reasonable to me.  As I laid out in a previous message I 
still think it appropriate in 10.3 to assume a single Collator for the
database and store it somewhere available at boot time before store
boots, and just let the datafactory somehow have it rather than make
store pass it in on every template object create.  I believe if someone
has a future itch to allow for more than one collator per db there is
existing support to allow for the upgrade.
> 
> Dan.
> 
> 
> 


Mime
View raw message