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 Lineitem DERBY-2599: Associating correct collation type and derivation with DTD
Date Mon, 30 Apr 2007 19:03:49 GMT
Currently, TypeDescriptorImpl has collation derivation of "implicit". I was
thinking that although it does not apply to non-collation sensitive
datatypes, it should be set to "none", but maybe it doesn't matter because
for non-collation sensitive datatypes, noone should worry about collation
derivation. So, if we decide on having collation type of "implicit" for
non-collation sensitive datatypes, then I guess we don't need to worry about
collation settings when such DTDs get created.

Also, Dan, I am assuming when you say setCollation(), you mean
setCollationType and setCollationDerivation methods on DTD. If we do want to
rely on those 2 methods rather than the DTD constructor, then I am
thinking that we should default the collation type to be UCS_BASIC on
TypeDescriptorImpl (right now, it is not initialized to anything). That way,
only character types with a possibility of TERRITORY_BASED/UCS_BASIC
collation will call setCollationType. But places like
DataDictionaryImpl.create_SYSCS_procedures, where we known collation type
can only be UCS_BASIC will not have to call setCollationType.

If this sounds fine, i will start looking at using setCollationType method
vs constructor.


On 4/30/07, Daniel John Debrunner <djd@apache.org> wrote:
> Mamta Satoor wrote:
> > Hi,
> >
> > I am working on putting the correct collation type and derivation for
> > DTDs. The approach I am taking is to change all the constructors for
> > DTDs to accept the collation type and derivation. It will be the
> > responsibility of the caller of the DTD constructor to pass this
> > information for all different kinds of DTDs, ie whether the DTD is for
> > collation sensitive datatypes (which include the character string
> > datatypes), or all the other non-collation sensitive datatypes (eg
> > numeric, binary etc,). For non collation sensitive datatypes, the caller
> > will pass collation derivation of "none" which will mean that collation
> > type of such datatypes should be ignored.
> >
> > I just wanted to bring it to community's attention that this approach of
> > changing the DTD constructor signature is requiring lot of changes since
> > all the callers now have to taken on the task of passing the collation
> > type and derivation. I think that is the right approach ie have callers
> > take on the responsibility of associating the collation types and
> > derivations for their DTDs. Let me know if anyone has any feedback on
> > how I am approaching this.
> Why not just a setCollation() method?
> Dan.

View raw message