db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-499) Expose BOOLEAN datatype to end users
Date Fri, 09 Dec 2005 03:19:58 GMT
Rick Hillegas (JIRA) wrote:

>Kathey, thank you for going through the network code so carefully. Some responses follow:
>0) I understand your misgivings. I do however see some value in rolling some ongoing cleanup
into patches. I tried to steer a middle course here: I moved the datatype ids to a common
file but I deferred the rototill of Typdef.java to a later submission. I hope this is ok.
Please let me know if you think this is a showstopper.
The only thing I would really like to see as a separate patch is the 
addition of the non-boolean types.  As for the reorganization and
renaming of the constants, that is just a personal  preference for
separation  if convenient for the future.  For example submit
Typedef.java changes all on their own.

>1) I certainly hope that the Open Group will finalize the new datatypes in the 10.2 timeframe.
It's a slow process. I don't see a conflict with Army's work on XML but Army and I can work
together on this.
Yes, good for that to get worked out on the list and another good reason
for the non Boolean changes to  go in as a separate patch.

>You are right, that if we include the DRDA types, we should include corresponding DB2
types. I will add these as more placeholders.
>2) Yes, the BOOLEANS are coming from the client as SMALLINT. I agree that it would be
better to send these as booleans. I will make that change. I will also make the other changes
you suggest here.
great.  I think that it would be good to check in this patch and then do
that work.

>3) I can add the CrossConverter code you suggest. But I can't answer your question: Obviously
the tests I have written don't stress this code. Can you help me understand what test cases
will stress this code?

parameterMapping might be a good bet also lang/procedure.java

Cross Converters was just one example that I happenned to see when
reviewing the patch.  I think there are other cases in the client where
all the types are handled but boolean is left out.  Perhaps they are all
related to setXXX methods which are still being handled like SMALLINT.  
I am guessing the  methods in CrossConverters may be covered with
setObject calls but I can't offer a better guess than that. You'd have
to look for references if they even exist #:)
Again it could wait until after your patch is committed.

>5i) I ran the compatibility suite in the following combinations:
[snip lots of combinations]

>7) I welcome your creative suggestions here. The best idea I have been able to come up
with is the running of the compatibility suite as part of some nightly or weekly verification.
A long time ago we  were discussing checking in the release
jars and then  the test can pick up on those to test trunk combinations in derbyAll with the current jvm.   Is that
a possibility?

Iincremental development is good.  With the exception of  separating out
the non boolean types I have no show stopper issues.


View raw message