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.
OK
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.
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.
OK
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.
Thanks.
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.
OK
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.
OK
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.
David
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: 10.1.1.0
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/
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
