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: Changes to comparable method in TypeCompiler
Date Wed, 11 Apr 2007 19:00:01 GMT
Army, I just finished updating the wiki page to reflect the fact that the
result character string from XMLSERIALIZE will have the same collation as
current schema's character set. It is part of number 6 on the wiki page
under section Collation Determination.

Mamta


On 4/11/07, Mamta Satoor <msatoor@gmail.com> wrote:
>
> Hi Army,
>
> Thanks for the sanity check on what I am proposing for comparable method.
>
> As for the changes required to instantiate the proper runtime class, ie
> SQLChar vs CollatorSQLChar, I plan to address that as part of Outstanding
> items section -> Language changes -> 3). I have not started looking at that
> yet. What I am working on is loading the correct collation type for various
> character types (Section Collation Determination) and disallowing comparison
> between character types with different collations at compile time.
>
> Thanks for bringing up XML.XMLSerialize(). I was not aware of it. I agree
> to the approach of "XMLSERIALIZE can be characterized in the same way as the
> CHAR and VARCHAR functions." I will update the wiki page for XMLSERIALIZE
> to reflect that.
>
> thanks a lot,
> Mamta
>
> On 4/11/07, Army <qozinx@gmail.com> wrote:
> >
> > Mamta Satoor wrote:
> > >
> > > What I am proposing is to change the comparable method from type 1 to
> > type
> > > 2. The reason for this is comparable method for character types should
> > also
> > > check the collation type and derivation while deciding whether the
> > method
> > > should return true or false. But since the collation information is
> > not
> > > associated with TypeId, we need to pass the TypeDescriptors of both
> > the
> > > types that need to be compared. In order to do this, I propose the
> > > comparable method to change as follows
> > >
> > > boolean    comparable(
> > >       DataTypeDescriptor leftType,
> > >       DataTypeDescriptor rightType,
> > >       boolean forEquals,
> > >       ClassFactory cf);
> > >
> > > This change would require that all the implementation of TC change and
> > all
> > > the callers of this method should change too.
> >
> > I spent some time looking at this approach and it seems pretty well
> > contained: a
> > search for "comparable" in the codeline shows that aside from the
> > TypeCompiler
> > classes themselves, only a few other files would be affected.  I tried
> > to think
> > some of alternative approaches but none seemed as contained as the one
> > you
> > suggest here.
> >
> > ----
> >
> > On a completely different note, while looking at the relevant classes I
> > noticed
> > that we instantiate the non-collator character types (ex. SQLChar) in
> > the
> > "getNull()" method of TypeId.  Do you have plans to update that piece of
> > code to
> > account for collator types?  Are any changes needed there?  I searched
> > the wiki
> > page for "TypeId" but nothing came up.
> >
> > And similarly, we instantiate the non-collator character types in the
> > XMLSerialize() method of iapi/types/XML.java.  While XML values
> > themselves are
> > not orderable/comparable with any other values (and thus collation
> > should not be
> > a problem), the result of an XMLSERIALIZE operator is a normal SQL
> > character
> > value, which can be compared.  So will the code in XML.XMLSerialize()
> > have to be
> > updated to account for collation?  My guess is that XMLSERIALIZE can be
> > characterized in the same way as the CHAR and VARCHAR functions (number
> > 6 on the
> > wiki page):
> >
> >   [XMLSERIALIZE] behavior can be defined as similar to CAST ie, the
> > result
> >   character string of [XMLSERIALIZE] will have the same collation as
> > current
> >   schema's character set. The collation derivation will be implicit.
> >
> > Does that sound right?
> >
> > Sorry if that's a tad off-topic...
> >
> > Army
> >
> >
>

Mime
View raw message