db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Thu, 15 Mar 2007 18:09:41 GMT
Mamta Satoor wrote:
> Dan, I understand your concern about changes required in many places in 
> the code to make sure that we get write instance of character datatype 
> ie SQLChar vs CollatorSQLChar.
> But I don't understand your following comment
> "My first thought is that this doesn't scale and doesn't seem like an OO
> solution. To think ahead this means any addition collation style will
> also add four new datatypes, which means there could easily be sixteen
> or more datatypes to represent the characters. Each datatype will come
> with some code cost, classes and/or methods per type."
> For any additional collation styles, CollatorSQLChar will just need to 
> be instantiated with proper RuleBasedCollator object for that collation 
> style. We wouldn't need to create 4 new datatype for every new collation 
> style introduced in Derby. Can you elaborate more on what you mean by 
> your comment above.

A type within Derby is made of up of more that the class that represents 
its value. A type compiler, data type object, methods in 
DataValueFactory that return that type. All of these would have to setup 
so that the new internal types for a specific collation can be handled.

I'm guessing at how you plan to implement this, but assume that a 
case-insensitive collation is later added based on lower:

  1) need new format identifiers, since current plan is to define 
type+collation only by format identifier

  2) thus two options at the CollatorSQLChar level
      a) have a variable per instance that defines the format id 
(additional runtime overhead)
      b) new class that extends CollatorSQLChar and returns different 
format id (additional footprint)

  3) 1 leads to new methods in DataValueFactory to get a 
DataValueDescriptor of the correct type, e.g. I assume you are planning 
to add getLocaleChar(String val) etc., now need getLowerChar(String val) 

  4) More logic and/or classes in the compilation and type system to 
handle these new types that I haven't thought in detail about.

Now some of the code could be shared, but this approach would make it so 
that adding a new collation has to go create four new internal types and 
ensure all code handles them correctly.


View raw message