db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Date Fri, 14 Oct 2005 02:55:16 GMT

Rick Hillegas (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-516?page=comments#action_12332013 ]

> Rick Hillegas commented on DERBY-516:
> -------------------------------------
> Thanks, David, for reviewing this patch so thoroughly. Based on your review, I will make
several changes and resubmit this patch. Here are my responses to your comments:
> 1) No-one else has run this test yet. Thank you for voluteering to do so. If the instructions
aren't clear enough, please let me know and I will fix them too.


> 2) Concerning the casing of my symbols: I have tried to follow the same casing policy
which I use in Java code. I uppercase constants and I camelcase variables, arguments, and

I am not sure if the same casing policy applies in Ant, at least I 
haven't seen that in the build.xml files we have.

> 3) It's true that the embedded case isn't properly speaking part of a compatibility test.
It's there as a sanity check to track discrepancies between the embedded and network clients.
I will add a comment to explain this.

OK, sounds good.

> 4) It's also true that jdbcTrunk is never invoked. It's a top level entry point which
I included to help me debug the test and harness. It lets you run just one combination. I
left it in because I expect it will be very useful as developers add additional cases to this
test. I will beef up its comment to explain this.


> 5) In general, I will beef up my comments. I apologize for the cryptic names TD and T_CN.
Originally these classes had more useful names: TypeDescriptor and TypeCoercion. I had to
truncate these names in order to fit the ALL_TYPES and COERCIONS tables onto a readable screen.
I think I've given up on this fond dream for ALL_TYPES and so there's no reason that TD couldn't
be replaced with its more useful name. I will make this change. I would like to leave T_CN
short for the reason I just gave, but I will add a comment to its class header explaining
this oddity.


> 6) Similarly, I opted for Y and _ instead of Y and N because it made the table more readable.
I experimented with a couple combinations and this is the one which made the salient Y really
leap out at the reader.

Perhaps you can add a comment to explain this; it takes a double-take 
reading the code to understand what's up here.

> 7) I agree with your objection to my exception handling in the startup code. I will fix
this as you suggest.


> 8) You are right, I am only testing the 10.0 datatypes in this first cut of the test.
As I re-enable and add new datatypes, I will incorporate them in this test too. When I add
a new datatype, it will be tested in all combinations in which the server lets a customer
declare that datatype. In the current state of the test, there is only one minor (canonized)
incompatibility, which I have logged as bug 584: the DRDA clients conflate NUMERIC and DECIMAL.
No doubt, as we add more test cases, we will find more important existing incompatibilities.


> I will also address the issue which you and Dan discussed in email: I will amend the
scripts and BUILDING.txt to tell the developer that she should be able to download any version
of JUnit at level 3.8.1 or higher.

OK, great.

It's looking good, once I do a run of the compatibility tests and they 
look OK it should be good to go.


>>Need to incorporate client backward/forward  compatibility testing into testing procedures.
>>         Key: DERBY-516
>>         URL: http://issues.apache.org/jira/browse/DERBY-516
>>     Project: Derby
>>        Type: Test
>>  Components: Test
>>    Versions:
>>    Reporter: Kathey Marsden
>>    Assignee: Rick Hillegas
>> Attachments: bug516.diff
>>Need to incorporate client backward/forward  compatibility testing into testing procedures.
>>New versions of the Derby network server should work with old versions of the network
client.  New versions of the Derby network client should work with old versions of the server.
 Currently that means that the 10.1 client should be tested on the trunk.     The 10.2 client
definitely needs to be tested with the 10.1  server before release, but it would be good to
start testing snapshots of 10.2 client on the 10.1 branch earlier.
>>Bug fixes may mean that the canons differ for different versions.
>>The test harness I think is set up to allow different masters for different versions.
 It at least has that functionality for the DerbyNet framework
>> and it could  be expanded to cover DerbyNetClient.  The way it works is that
>>the harness checks for a masters in the following order:

View raw message