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: DERBY-1478 : Making the correct collation type available in CreateTableNode for character string type columns
Date Thu, 05 Apr 2007 17:30:39 GMT
Just one clarificaiton, the reason I am having SD's constructor call DD to
get the collation type rather than collationType simply getting passed to
SD's constructor is that the later approach would require us to change all
the places where a SD object is created and have them pass the additional
collationType parameter to it's constructor. I searched through the code and
there are several places where we create a SD.

With my approach, we have to change code in only one place and that would be
in SD's constructor (and ofcourse we need changes in DD as explained in my
mail earlier. But the changes in DD are require no matter how SD gets the
right value in it's collationType field).

Mamta


On 4/5/07, Mamta Satoor <msatoor@gmail.com> wrote:
>
> Here is what I am thinking of how to make the correct default collation
> Type available in SchemaDescriptor(SD).
>
> DataDictionary(DD) will have two additional fields and two additional
> apis. The field names will be
> int collationTypeOfSystemSchemas
> int collationTypeOfUserSchemas
> The apis associated with them would be
> public int getCollationTypeOfSystemSchemas()
> public int getCollationTypeOfUserSchemas()
> DD in it's boot method will initialize collationTypeOfSystemSchemas to
> StringDataValue.COLLATION_TYPE_UCS_BASIC In the same boot method, it will
> check the collation property supplied through optional JDBC attribute
> COLLATION and set collationTypeOfUserSchemas to
> StringDataValue.COLLATION_TYPE_UCS_BASIC  or
> StringDataValue.COLLATION_TYPE_TERRITORY_BASED. This covers the changes
> required in DD.
>
> Now coming to SD. SD will have a new field
> int collationType
> It will have a new api called
> public int getCollationType()
> This new field will get initialized in SD's constructor. SD's constructor
> already gets DD and isSystem passed to it. SD can use these 2 parameters to
> initialize collationType. The additional code in SD's constructor would look
> something like this
> if (isSystem) //check if I am a system schema
>    collationType = DD.getCollationTypeOfSystemSchemas();
> else
>     collationType = DD.getCollationTypeOfUserSchemas();
>
> I will go ahead and start implementing this. If anyone has any feedback,
> please let me know.
> Mamta
>
>
> On 4/4/07, Daniel John Debrunner <djd@apache.org> wrote:
> >
> > Mamta Satoor wrote:
> > > Yes, I thought of going that track, but that would involve saving the
> > > collation type in SYSCHEMAS and thus some hard upgrade code. In soft
> > > upgrade, we can't upgrade SYSCHEMAS, so some mechanism to have it
> > > default to UCS_BASIC.
> >
> > No, no need to save anything in SYSSCHEMAs. The data dictionary could
> > set the schema's default collation default type when loading.
> > SchemaDescriptor has a isSystemSchema() method so it's clear which are
> > system schemas and which are not.
> >
> >
> > Dan.
> >
> > >
> >
> > >
> > >     The collation you are looking for is a property of the schema, see
> > this
> > >     from your 1478 wiki page:
> > >
> > >      > 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>.
> > >
> > >     Thus, since it's a property of the schema, the most logical place
> > for
> > >     this is as a method on SchemaDescriptor,
> > >     e.g.
> > >
> > >     public int getCollationType();
> > >
> > >
> > >     Dan.
> > >
> > >
> > >
> >
> >
> >
>

Mime
View raw message