db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: Collation implementation WAS Re: Should COLLATION attribute related code go in BasicDatabase?
Date Wed, 21 Mar 2007 14:22:54 GMT
I understand point 2. My question was an attempt to understand point 1, ie
why and when will we need to change the collate from TERRITORY_BASED to
UCS_BASIC? I know that we will need this support in future when we will
support the SQL's COLLATE clause. For instance, on a CAST, SQL spec allows
you to specify COLLATE clause. In a case like that, when we do start
supporting COLLATE clause, we might need to go from TERRITORY_BASED to
UCS_BASIC. When you mention 1) in the mail below, is that the use case you
were thinking of this method in CollatorSQLChar? Or is there already a need
today with the current design, that we will want to go from TERRITORY_BASED
collation to UCS_BASIC collation?

thanks,
Mamta

On 3/21/07, Daniel John Debrunner <djd@apache.org> wrote:
>
> Mamta Satoor wrote:
> > Dan, why would we need to override the StringDataValue
> > getValue(RuleBasedCollator collation) method in CollatorSQLChar? I think
> > it will be sufficient to implement this method in SQLChar with following
> > pseudocode
> > StringDataValue getValue(RuleBasedCollator collation)
> > {
> >    if (collation == null)
> >    {
> >      // Just need UCS_BASIC collation, so just return myself.
> >      return this;
> >    }
> >
> >     CollatorSQLChar s = new CollatorSQLChar();
> >     s.setValue(this);
> >      s.setCollator(collation);
> >     return s;
> > }
> >
> >
> > I see this method being called when store is trying to construct a
> > template row of DVDs based on the format ids and collation type that
> > store is aware of. Since the formatid for character types will always
> > correspond to SQLChar (the base class)(for simplicity, I am only talking
> > in terms of SQL type CHAR. Same logic applies for other SQL
> > character types) , the only thing that store might want is to use the
> > super class CollatorSQLChar as DVD if the collation type is
> > 1(TERRITORY_BASED). When do you see the need for Derby code wanting to
> > go from CollatorSQLChar to SQLChar?
>
> 1) When needing to collate using USC_BASIC.
>
> 2) If CollatorSQLChar does not override that getValue(RuleBasedCollator
> collation) then the class would not be honoring the api contract, which
> will eventually lead to bugs as other new code assumes the class is
> honoring the contract of the api.
>
> Dan.
>
>
>
>

Mime
View raw message