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] Excellent! >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 10.1.1.0 release jars and then the test can pick up on those to test 10.1.1.0/ 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. Kathey
