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, 18 Apr 2007 22:05:36 GMT
Hi Dan,

Thanks for your feedback on this topic.

You asked "In this instance (& I see from your post that the class already
has this problem) does the compare method on CharTypeCompiler have to
support arbitrary comparable checks, e.g. Blob against INTEGER?" I am not
sure I understand the question. If you are asking without collation type
changes, is the current CharTypeCompiler in Derby 10.3 have to
support arbitrary comparable checks, then I don't know answer to it. It
looks like from CharTypeCompiler.comparable() method implementation, that it
definitely accepts all character types, date, time, timestamp, boolean and
user types(which Derby does not support anymore).

I was working on the mindset that we need to now have collation involved
when TypeCompiler decides what the outcome of comparable should be. But
current TypeCompiler does not have collation information. One alternative
can be to store collation information in CharTypeCompiler and then
comparable implementation in CharTypeCompiler can use collation in trying to
decide outcome of comparable.

I think what you are suggesting is to move comparable method out from the
TypeCompiler and into DataTypeDescriptor altogether. So, the existing code,
where we use TypeCompiler to decide if 2 types can be compared or not should
now call a method on DTD to determine comparability. This might be cleaner
than stuffing collation information in CharTypeCompiler but I am just
wondering why was comparable not defined on DTD at the very start. Why do we
go through TypeCompiler and what functionality does TypeCompiler provide
that DTD does not? In other words, I don't understand the connection between
TypeCompiler and DTD and how they fit together.


On 4/18/07, Daniel John Debrunner <djd@apache.org> wrote:
> Mamta Satoor wrote:
> > This is the background information about how there are 2 different kinds
> of methods in TC. One type that uses the TypeId associated with BTC to
> implement the methods and the other type which ignore TypeId and just uses
> the passed parameters to provide the method implementation.
> >
> > 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);
> "other type which ignore TypeId"  -- This is a good indication in oo
> programming that the method is defined on the wrong interface. That is,
> if a method is defined to ignore the type is declared on then that's not
> good oo style. In this instance (& I see from your post that the class
> already has this problem) does the compare method on CharTypeCompiler
> have to support arbitrary comparable checks, e.g. Blob against INTEGER?
> In situations like this one can typically determine the correct
> interface for the method declaration from the parameter types that are
> used, e.g. in this case DataTypeDescriptor seems the logical choice.
> The data type system is full of inconsistent methods, e.g. the add
> method on DataValueDescriptor (DVD) is something like
>    DVD add (DVD left, DVD right, DVD result)
> This indicates the actual instance the method is called upon has no
> input on the result which is just not good. Alternate signatures that
> make more sense would be:
> // set result = this+other
> void add(DVD other, DVD result)
> // set this = left+right
> void add(DVD left, DVD right)
> This is actually more that just good style, the signature of this add
> method (and other methods) has lead to a programming style that results
> in extra checks and field assignments for every addition thus decreasing
> performance. Either one of the alternate signatures would have avoided
> those issues up front.
> Dan.

View raw message