Mamta Satoor wrote:
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
Thanks, Dan. This information was very helpful.
And thanks, Bryan, for always capturing different pieces of information from
Derby mailing list and putting it together on Derby wiki. It will surely be
helpful to others.
Mamta
On 4/19/07, Daniel John Debrunner [EMAIL PROTECTED] wrote:
Mamta
I am working on moving the comparable method from TypeCompiler to
DataTypeDescriptor. While doing that, I have found that most TypeCompiler
implementations in their comparable method do quite a bit of coding to deal
with user types. I thought Derby does not support user types anymore. To
clean
Mamta Satoor wrote:
I am working on moving the comparable method from TypeCompiler to
DataTypeDescriptor. While doing that, I have found that most
TypeCompiler implementations in their comparable method do quite a bit
of coding to deal with user types. I thought Derby does not support user
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
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.
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
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
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
Mamta Satoor wrote:
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.
Thanks Mamta.
Hi,
One of the methods in TypeCompiler(TC) interface is
booleancomparable(
TypeId otherType,
boolean forEquals,
ClassFactory cf);
The abstract class implementation of TC is BaseTypeCompiler(BTC) and BTC has
a private field called correspondingTypeId which is used as one
11 matches
Mail list logo
