db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Date Thu, 13 Oct 2005 16:10:07 GMT
    [ 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 methods.

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.

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.

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.

> 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.
> Note:
> 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:
> functionTests/master/<framework>/ver<version>  
> functionTests/master/<framework>/
> functionTests/master/

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message