You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Ramandeep Kaur <ra...@gmail.com> on 2006/01/13 20:22:50 UTC
Server and client compatibility test for 10.2 and 10.1
Hi,
I ran suite derbynetclientmats to test Server and Client compatibility for
the following combinations:-
Server: 10.2 (svn 368249), Client: 10.1 (svn 368246),
derbyTesting.jar: 10.1(svn 368246)
Server: 10.1 (svn 368246), Client: 10.2 (svn 367899),
derbyTesting.jar: 10.1 (svn
368246)
Server: 10.2, Client: 10.1, derbyTesting.jar: 10.1
---------------------------------------------------------------------
jvms: jdk15, ibm142
Test failures:
derbynetclientmats/derbynetmats/derbynetmats.fail:derbynet/NSinSameJVM.java
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/autoGeneratedJdbc30.java
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
derbynetclientmats/derbynetmats/derbynetmats.fail:lang/procedure.java
derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
derbynetclientmats/derbynetmats/derbynetmats.fail:lang/syscat.sql
Server: 10.1, Client: 10.2, derbyTesting.jar: 10.1
---------------------------------------------------------------------
jvms: jdk15, ibm142
Test failures:
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql
derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java
After looking at the failures, I have found that failures could be due to:
- Error message changes from one version to another. Hence creating diff.
- Messages with version number which is different. hence creating diff.
- Changes due to bug fixes.
I will look into the failures more. I am attaching the report files for
results ran with jdk15 only. If you get a chance, please look at the
failures and provide me your feedback.
Thanks,
Ramandeep Kaur (ramandhindsa@gmail.com)
Re: Server and client compatibility test for 10.2 and 10.1
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I looked at the failure in checkDataSource (see below) and it's not
clear to me why running with a 10.1 client and a 10.2 server should
cause this error to occur (see below - it happens twice).
Note that the underlying EmbedConnection is the same, but the wrapping
BrokeredConnection is different (which actually is correct). This seems
like a bug in the test, actually.
I'll log a JIRA, I have some other things on my plate that are higher
priority for me. If someone feels this is blocking them, please up the
priority in the JIRA item, let me know, and I'll get on it.
I'll include a hint on how to fix it if anyone is motivated to jump on this.
David
java.lang.Exception: Two connections from the same pooled connection
have different string values:
org.apache.derby.iapi.jdbc.BrokeredConnection30@19492125, Wrapped
Connection = org.apache.derby.impl.jdbc.EmbedConnection30@22199751 (XID
= 164), (SESSIONID = 33), (DATABASE = wombat), (DRDAID = null) ,
org.apache.derby.iapi.jdbc.BrokeredConnection30@12231451, Wrapped
Connection = org.apache.derby.impl.jdbc.EmbedConnection30@22199751 (XID
= 164), SESSIONID = 33), (DATABASE = wombat), (DRDAID = null)
Kathey Marsden wrote:
> Ramandeep Kaur wrote:
>
>
>>Hi,
>>
>>I ran regression testing with 10.2.0.0 alpha - 372715 (except
>>derbyTesting.jar) and 10.1 derbyTesting.jar file.
>>
>>Summary
>>--------------
>>OS: Windows 2000, JVM: sun jdk 142
>>599 Tests Run
>>90% Pass (536 tests passed)
>>10% Fail (63 tests failed)
>>1 Suites skipped
>>
>>
>
> Thanks so much Raman. Maybe file a Jira Task to analyze the results.
> Perhaps folks will recognize tests on the list affected by areas where
> they worked or are interested in doing a more comprehensive analysis.
> I would interested to see the reasons that tests failed so we could
> consider.those cases for automating this testing.
>
> On a *super* brief browse the checkDataSource diff looked interesting.
> Perhaps David could tell us if that is expected or not.
>
> Kathey
>
>
Re: Server and client compatibility test for 10.2 and 10.1
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Thanks, Kathey, I re-read your proposal. I guess in principle I think
this is a good thing, but it seems like an awful amount of work. But I
am open to holding this as a vision and supporting it; backward
compatibility is a very important feature, I think we all agree.
I think ConnectionEnv is a better name than Behavior(iour/ioure)Checker
David
Kathey Marsden wrote:
> Daniel John Debrunner wrote:
>
>
>>David W. Van Couvering wrote:
>>
>>
>>
>>
>>>I'll check this diff, but one quick comment: a lot of these diffs look
>>>like formatting diffs. Shouldn't we be using the 10.2 canons even if we
>>>are using applications built against 10.1?
>>>
>>>
>>
>>No. Think of the 10.1 tests as an existing customer application. Any
>>changes seen by the tests may also be seen by real customer
>>applications. I'm suprised there were that many failures, though I
>>haven't seen the breakdown. I could see the addition of SQLStates for
>>client messages would make a number of tests fail.
>>
>>
>>
>>
>
> I posted a proposal earlier on this thread regarding how to possiblly
> automate this testing for java based tests and would appreciate your
> input. This proposal offers no solution for .sql tests, which present
> a large number of diffs, but my thought is that moving forward we will
> be moving mostly to java assertion based testing.
> http://www.mail-archive.com/derby-dev@db.apache.org/msg12668.html
>
> In the context of the JUnit discussion, I was thinking that instead of
> BehaviourChecker the class be called ConnectionEnv so it can
> potentially be expanded to include JVM based logic as well. So your
> test would have somthing like:
>
> import org.apache.derby.functionTests.util.ConnectionEnv;
>
> ConnectionEnv connenv = new ConnectionEnv(conn);
> if (connenv.supportsXXX())
> ......
>
> in ConnectionEnv, supportsXXX() will make the decision based on
> driver, database version, driver version, jvm etc.
>
>
> Kathey
>
>
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
>David W. Van Couvering wrote:
>
>
>
>>I'll check this diff, but one quick comment: a lot of these diffs look
>>like formatting diffs. Shouldn't we be using the 10.2 canons even if we
>>are using applications built against 10.1?
>>
>>
>
>No. Think of the 10.1 tests as an existing customer application. Any
>changes seen by the tests may also be seen by real customer
>applications. I'm suprised there were that many failures, though I
>haven't seen the breakdown. I could see the addition of SQLStates for
>client messages would make a number of tests fail.
>
>
>
>
I posted a proposal earlier on this thread regarding how to possiblly
automate this testing for java based tests and would appreciate your
input. This proposal offers no solution for .sql tests, which present
a large number of diffs, but my thought is that moving forward we will
be moving mostly to java assertion based testing.
http://www.mail-archive.com/derby-dev@db.apache.org/msg12668.html
In the context of the JUnit discussion, I was thinking that instead of
BehaviourChecker the class be called ConnectionEnv so it can
potentially be expanded to include JVM based logic as well. So your
test would have somthing like:
import org.apache.derby.functionTests.util.ConnectionEnv;
ConnectionEnv connenv = new ConnectionEnv(conn);
if (connenv.supportsXXX())
......
in ConnectionEnv, supportsXXX() will make the decision based on
driver, database version, driver version, jvm etc.
Kathey
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Daniel John Debrunner <dj...@apache.org>.
David W. Van Couvering wrote:
> I'll check this diff, but one quick comment: a lot of these diffs look
> like formatting diffs. Shouldn't we be using the 10.2 canons even if we
> are using applications built against 10.1?
No. Think of the 10.1 tests as an existing customer application. Any
changes seen by the tests may also be seen by real customer
applications. I'm suprised there were that many failures, though I
haven't seen the breakdown. I could see the addition of SQLStates for
client messages would make a number of tests fail.
Dan.
Re: Server and client compatibility test for 10.2 and 10.1
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I'll check this diff, but one quick comment: a lot of these diffs look
like formatting diffs. Shouldn't we be using the 10.2 canons even if we
are using applications built against 10.1?
David
Kathey Marsden wrote:
> Ramandeep Kaur wrote:
>
>
>>Hi,
>>
>>I ran regression testing with 10.2.0.0 alpha - 372715 (except
>>derbyTesting.jar) and 10.1 derbyTesting.jar file.
>>
>>Summary
>>--------------
>>OS: Windows 2000, JVM: sun jdk 142
>>599 Tests Run
>>90% Pass (536 tests passed)
>>10% Fail (63 tests failed)
>>1 Suites skipped
>>
>>
>
> Thanks so much Raman. Maybe file a Jira Task to analyze the results.
> Perhaps folks will recognize tests on the list affected by areas where
> they worked or are interested in doing a more comprehensive analysis.
> I would interested to see the reasons that tests failed so we could
> consider.those cases for automating this testing.
>
> On a *super* brief browse the checkDataSource diff looked interesting.
> Perhaps David could tell us if that is expected or not.
>
> Kathey
>
>
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Kathey Marsden <km...@sbcglobal.net>.
Ramandeep Kaur wrote:
> Hi,
>
>I ran regression testing with 10.2.0.0 alpha - 372715 (except
>derbyTesting.jar) and 10.1 derbyTesting.jar file.
>
>Summary
>--------------
>OS: Windows 2000, JVM: sun jdk 142
>599 Tests Run
>90% Pass (536 tests passed)
>10% Fail (63 tests failed)
>1 Suites skipped
>
>
Thanks so much Raman. Maybe file a Jira Task to analyze the results.
Perhaps folks will recognize tests on the list affected by areas where
they worked or are interested in doing a more comprehensive analysis.
I would interested to see the reasons that tests failed so we could
consider.those cases for automating this testing.
On a *super* brief browse the checkDataSource diff looked interesting.
Perhaps David could tell us if that is expected or not.
Kathey
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Ramandeep Kaur <ra...@gmail.com>.
Hi,
I ran regression testing with 10.2.0.0 alpha - 372715 (except
derbyTesting.jar) and 10.1 derbyTesting.jar file.
Summary
--------------
OS: Windows 2000, JVM: sun jdk 142
599 Tests Run
90% Pass (536 tests passed)
10% Fail (63 tests failed)
1 Suites skipped
Failed Tests
------------------
derbyall/derbyall.fail:jdbcapi/metadata.java
derbyall/derbyall.fail:jdbcapi/odbc_metadata.java
derbyall/derbyall.fail:lang/LOB.sql
derbyall/derbyall.fail:lang/aggregate.sql
derbyall/derbyall.fail:lang/altertable.sql
derbyall/derbyall.fail:lang/authorize.sql
derbyall/derbyall.fail:lang/autoincrement.sql
derbyall/derbyall.fail:lang/checkConstraint.sql
derbyall/derbyall.fail:lang/compressTable.sql
derbyall/derbyall.fail:lang/db2Compatibility.sql
derbyall/derbyall.fail:lang/dcl.sql
derbyall/derbyall.fail:lang/declareGlobalTempTableJava.java
derbyall/derbyall.fail:lang/implicitConversions.sql
derbyall/derbyall.fail:lang/logStream.java
derbyall/derbyall.fail:lang/logop.sql
derbyall/derbyall.fail:lang/primarykey.sql
derbyall/derbyall.fail:lang/procedure.java
derbyall/derbyall.fail:lang/refActions1.sql
derbyall/derbyall.fail:lang/schemas.sql
derbyall/derbyall.fail:lang/subquery.sql
derbyall/derbyall.fail:lang/syscat.sql
derbyall/derbyall.fail:lang/updatableResultSet.java
derbyall/derbyall.fail:lang/valuesclause.sql
derbyall/derbyall.fail:lang/views.sql
derbyall/derbyall.fail:jdbcapi/checkDataSource.java
derbyall/derbyall.fail:jdbcapi/metadataJdbc20.java
derbyall/derbyall.fail:jdbcapi/connectionJdbc20.java
derbyall/derbyall.fail:jdbcapi/autoGeneratedJdbc30.java
derbyall/derbyall.fail:jdbcapi/dbMetaDataJdbc30.java
derbyall/derbyall.fail:jdbcapi/checkDataSource30.java
derbyall/derbyall.fail:jdbcapi/LOBTest.java
derbyall/derbynetclientmats/derbynetmats.fail:derbynet/NSinSameJVM.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/autoGeneratedJdbc30.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/metadata.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
derbyall/derbynetclientmats/derbynetmats.fail:lang/forupdate.sql
derbyall/derbynetclientmats/derbynetmats.fail:lang/procedure.java
derbyall/derbynetclientmats/derbynetmats.fail:lang/updatableResultSet.java
derbyall/derbynetclientmats/derbynetmats.fail:lang/syscat.sql
derbyall/derbynetclientmats/derbynetmats.fail:store/holdCursorJDBC30.sql
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/LOBTest.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/blobclob4BLOB.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/parameterMapping.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java
derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java
derbyall/derbynetmats/derbynetmats.fail:derbynet/NSinSameJVM.java
derbyall/derbynetmats/derbynetmats.fail:jdbcapi/autoGeneratedJdbc30.java
derbyall/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
derbyall/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
derbyall/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
derbyall/derbynetmats/derbynetmats.fail:lang/procedure.java
derbyall/derbynetmats/derbynetmats.fail:lang/syscat.sql
derbyall/encryptionAll/encryptionAll.fail:store/access.sql
derbyall/encryptionAll/encryptionAll.fail:store/access.sql
derbyall/encryptionAll/encryptionAll.fail:store/access.sql
derbyall/encryptionAll/encryptionAll.fail:store/access.sql
derbyall/encryptionAll/encryptionAll.fail:store/access.sql
derbyall/encryptionAll/storemats.fail:store/access.sql
derbyall/encryptionAll/storemats.fail:store/streamingColumn.java
derbyall/storeall/storeall.fail:storetests/st_1.sql
derbyall/storeall/storemats.fail:store/access.sql
derbyall/storeall/storemats.fail:store/streamingColumn.java
I am attaching report file.
Ramandeep Kaur
ramandhindsa@gmail.com
Re: Server and client compatibility test for 10.2 and 10.1
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Great stuff, thanks Raman.
David
Ramandeep Kaur wrote:
> On 1/26/06, *Kathey Marsden* <kmarsdenderby@sbcglobal.net
> <ma...@sbcglobal.net>> wrote:
>
> Ramandeep Kaur wrote:
>
> >Thanks to Kathey for proposed solution.
> >
> >1. As per task 1, I have opened JIRA issues for failed tests:-
> >http://issues.apache.org/jira/browse/DERBY-880
> >http://issues.apache.org/jira/browse/DERBY-881
> <http://issues.apache.org/jira/browse/DERBY-881>
> >
> >
> Thank you Raman for doing this testing, finding these issues, and
> looking at the harness for the first step.
>
> One thing that Dan mentioned would provide great additional regression
> testing would be one more combination.
> 10.2. server, 10.2 client and 10.1 derbyTesting.jar and run the whole
> of derbyall.
>
> Kathey
>
> That is good idea. I will run the tests and will post the results.
>
>
> --
> Ramandeep Kaur
> ramandhindsa@gmail.com <ma...@gmail.com>
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Ramandeep Kaur <ra...@gmail.com>.
On 1/26/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
> Ramandeep Kaur wrote:
>
> >Thanks to Kathey for proposed solution.
> >
> >1. As per task 1, I have opened JIRA issues for failed tests:-
> >http://issues.apache.org/jira/browse/DERBY-880
> >http://issues.apache.org/jira/browse/DERBY-881
> >
> >
> Thank you Raman for doing this testing, finding these issues, and
> looking at the harness for the first step.
>
> One thing that Dan mentioned would provide great additional regression
> testing would be one more combination.
> 10.2. server, 10.2 client and 10.1 derbyTesting.jar and run the whole
> of derbyall.
>
> Kathey
>
That is good idea. I will run the tests and will post the results.
--
Ramandeep Kaur
ramandhindsa@gmail.com
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Kathey Marsden <km...@sbcglobal.net>.
Ramandeep Kaur wrote:
>Thanks to Kathey for proposed solution.
>
>1. As per task 1, I have opened JIRA issues for failed tests:-
>http://issues.apache.org/jira/browse/DERBY-880
>http://issues.apache.org/jira/browse/DERBY-881
>
>
Thank you Raman for doing this testing, finding these issues, and
looking at the harness for the first step.
One thing that Dan mentioned would provide great additional regression
testing would be one more combination.
10.2. server, 10.2 client and 10.1 derbyTesting.jar and run the whole
of derbyall.
Kathey
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Ramandeep Kaur <ra...@gmail.com>.
Thanks to Kathey for proposed solution.
1. As per task 1, I have opened JIRA issues for failed tests:-
http://issues.apache.org/jira/browse/DERBY-880
http://issues.apache.org/jira/browse/DERBY-881
2. I will work on task 2 to skip failing tests while running server and
client compatibility testing.
In the mean time, hopefully we will have some more input on other proposals
from Kathey.
Ramandeep Kaur
ramandhindsa@gmail.com
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Myrna van Lunteren <m....@gmail.com>.
On 1/20/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
> Myrna van Lunteren wrote:
>
> >
> >I think there's another change required in the test harness to support
> this
> >type of testing. There'll be need for test skipping, for sed-ing, and
> >(hopefully minimal) canons for diffing. Is that being implemented?
> >
> > I imagine something similar to what is currently in place for different
> JCC
> >clients.
> >
> >However, with the JCC clients, we always use the derbyTesting.jar of the
> >server level.
> >
> The more I think about it, the JCC model for the test harness is not
> right. I think Raman has it right to test with the lower rev testing
> jar. The product should always work at least at the level provided by
> Min(serverVersion,clientVersion) and that is what she is testing. As
> you mention, if you test with the newer testing jar and an older client
> or server, the number of tests that can be run as new features are
> added and the tests change will deteriorate rapidly.
>
> This is what I propose as a quick way to be able to run these tests
> and a reasonable model moving forward.
> Summary
> - Log a Jira entry for the likely regression.
> - Create a new test harness property runwithMixedVersions=<true |
> false> default true
> - Create a BehaviourChecker class which tests can use to check expected
> product behaviour
> - Update 10.1 tests as needed to use the runwithMixedVersions property
> or BehaviourChecker methods
>
> Details below:
>
> 1) File a high priority Jira issue for the one apparent regression
> found. <>(Stream of column value in result cannot be retrieved twice
> error in connectionJdbc20.java and LobTest.java)
>
> 2) Add a property to the test harness, runwithMixedVersions=<true |
> false> default true
> This property would mean that the test would not run at all if the
> server and client are different versions This is a quick way to get
> the suite running cleanly.
>
> 3)In the functionalTests/util directory we make a BehaviourChecker class
> (or better name) which tests can use to check the behaviour based on
> combinations, drivers or whatever. It will take a connection in the
> constructor and will have methods like
> closesForwardOnlyRSOnFetchOfLastRow() or
> supportsAutogeneratedKeysForMultipleRowInserts() which check the
> DatabaseMetaData to make the right decision. For example,
> closesForwardOnlyRSOnFetchOfLastRow() will be true for JCC and false
> if the driverVersiion is greater than or equal to 10.2 (DERBY-213).
>
> 3) In the 10.1 branch, set the property for the failing tests. Hopefully
> someone will start weekly runs with 10.1/10.2 combinations.
>
> 4) Java tests that need to handle different behaviour in order to pass
> can either do something generic to resolve the problem or use
> BehaviourChecker to do the right thing. Always the tests are being
> changed in the lower level branch, right now that means 10.1.
>
> Examples:
> derbynet/NSinSameJVM.java
> Test fails because network server no longer outputs connections to the
> console by default. The test can be enabled by changing the location of
> the console output for the test, since it is not the console output
> being tested.
jdbcapi/autoGeneratedJdbc30.java
> Test fails because of different results with (10.1 client/10.2
> server). The 10.1 test could be be enabled by.
>
> 1) Add a method to BehaviourChecker
> public boolean suppportsAutogeneratedKeysOnMultipleRowInsert()
> {
> // if database version from DatabaseMetaData
> greatThanOrEqualTo(10,2,0) return true
> // code left as excercise for the reader.
> }
>
> 2) Change the test
> BehaviourChecker checker = new BehaviourChecker(conn);
> ....
> if (checker.suppportsAutogeneratedKeysOnMultipleRowInsert())
> {
> // expect one thing
> }
> else
> {
> // expect something else
> }
>
>
> Pros as I see it:
> - We keep messy test changes in the old branches.
> - We avoid excluding entire tests because of expected differences or a
> single issue
> - BehaviourChecker has the beneficial side effect of documenting
> expected behaviour.
> - BehaviourChecker could be expanded to handle a lot of the harness
> property functionality as well as replace the various framework
> checking logic in the individual tests.
>
>
> Cons
> - It is just not going to work for .sql tests.
> - Those interested in maintaining this testing will have to do work in
> the maintenance branches, but I just don't see a way around that and it
> keeps our trunk tests clean.
> - Behaviour is spelled different ways by different people so probably a
> different name would be better.
>
> Kathey
Makes sense.
re sql tests - I found, at least in main, while looking for the 'excludeJCC'
property we have in the test harness, (which apparently is currently not
used in any test properties file) that possibly the harness will look for
canons for clients in directories ver + major number + minor number, e.g. '
ver10.1'. or 'ver10.2'. It looked like it tries this whether the client is
DerbyNet or DerbyNetClient. Worthwhile checking into for whomever is going
to do this? This interesting bit of code is in harness/FileCompare.java.
I've not tested it.
Myrna
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Daniel John Debrunner <dj...@apache.org>.
Kathey Marsden wrote:
> Myrna van Lunteren wrote:
<snipped - lots of good suff about testing cross versions>
It occured to me the other day, and maybe this was the intention, that
this testing is not limited to network server and clients.
I should be able to run
java -cp derby10.1/derbyTesting.jar:derby10.2/derby.jar
org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
Any failures should be explainable by changes to 10.2, or they are
regressions.
Dan.
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Kathey Marsden <km...@sbcglobal.net>.
Myrna van Lunteren wrote:
>
>I think there's another change required in the test harness to support this
>type of testing. There'll be need for test skipping, for sed-ing, and
>(hopefully minimal) canons for diffing. Is that being implemented?
>
> I imagine something similar to what is currently in place for different JCC
>clients.
>
>However, with the JCC clients, we always use the derbyTesting.jar of the
>server level.
>
The more I think about it, the JCC model for the test harness is not
right. I think Raman has it right to test with the lower rev testing
jar. The product should always work at least at the level provided by
Min(serverVersion,clientVersion) and that is what she is testing. As
you mention, if you test with the newer testing jar and an older client
or server, the number of tests that can be run as new features are
added and the tests change will deteriorate rapidly.
This is what I propose as a quick way to be able to run these tests
and a reasonable model moving forward.
Summary
- Log a Jira entry for the likely regression.
- Create a new test harness property runwithMixedVersions=<true |
false> default true
- Create a BehaviourChecker class which tests can use to check expected
product behaviour
- Update 10.1 tests as needed to use the runwithMixedVersions property
or BehaviourChecker methods
Details below:
1) File a high priority Jira issue for the one apparent regression
found. <>(Stream of column value in result cannot be retrieved twice
error in connectionJdbc20.java and LobTest.java)
2) Add a property to the test harness, runwithMixedVersions=<true |
false> default true
This property would mean that the test would not run at all if the
server and client are different versions This is a quick way to get
the suite running cleanly.
3)In the functionalTests/util directory we make a BehaviourChecker class
(or better name) which tests can use to check the behaviour based on
combinations, drivers or whatever. It will take a connection in the
constructor and will have methods like
closesForwardOnlyRSOnFetchOfLastRow() or
supportsAutogeneratedKeysForMultipleRowInserts() which check the
DatabaseMetaData to make the right decision. For example,
closesForwardOnlyRSOnFetchOfLastRow() will be true for JCC and false
if the driverVersiion is greater than or equal to 10.2 (DERBY-213).
3) In the 10.1 branch, set the property for the failing tests. Hopefully
someone will start weekly runs with 10.1/10.2 combinations.
4) Java tests that need to handle different behaviour in order to pass
can either do something generic to resolve the problem or use
BehaviourChecker to do the right thing. Always the tests are being
changed in the lower level branch, right now that means 10.1.
Examples:
derbynet/NSinSameJVM.java
Test fails because network server no longer outputs connections to the
console by default. The test can be enabled by changing the location of
the console output for the test, since it is not the console output
being tested.
jdbcapi/autoGeneratedJdbc30.java
Test fails because of different results with (10.1 client/10.2 server). The 10.1 test could be be enabled by.
1) Add a method to BehaviourChecker
public boolean suppportsAutogeneratedKeysOnMultipleRowInsert()
{
// if database version from DatabaseMetaData
greatThanOrEqualTo(10,2,0) return true
// code left as excercise for the reader.
}
2) Change the test
BehaviourChecker checker = new BehaviourChecker(conn);
....
if (checker.suppportsAutogeneratedKeysOnMultipleRowInsert())
{
// expect one thing
}
else
{
// expect something else
}
Pros as I see it:
- We keep messy test changes in the old branches.
- We avoid excluding entire tests because of expected differences or a
single issue
- BehaviourChecker has the beneficial side effect of documenting
expected behaviour.
- BehaviourChecker could be expanded to handle a lot of the harness
property functionality as well as replace the various framework
checking logic in the individual tests.
Cons
- It is just not going to work for .sql tests.
- Those interested in maintaining this testing will have to do work in
the maintenance branches, but I just don't see a way around that and it
keeps our trunk tests clean.
- Behaviour is spelled different ways by different people so probably a
different name would be better.
Kathey
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Myrna van Lunteren <m....@gmail.com>.
On 1/16/06, Kathey Marsden <km...@sbcglobal.net> wrote:
> Ramandeep Kaur wrote:
>
> >Thanks to Kathey for looking into test failures.
> >
> >Attaching tmp and tmpstr files for autoGeneratedJdbc30 and
> holdCursorJDBC30.
> >
> >Please check out the attachments.
> >
> >
> These do not look like compatibility problems.
>
> holdCursorJDBC30 - Output changed with fix for DERBY-213
> autoGeneratedJdbc30 matches the 10.2 master and looks like a changed
> output from the fix for DERBY-353.
I think there's another change required in the test harness to support this
type of testing. There'll be need for test skipping, for sed-ing, and
(hopefully minimal) canons for diffing. Is that being implemented?
I imagine something similar to what is currently in place for different JCC
clients.
However, with the JCC clients, we always use the derbyTesting.jar of the
server level. Because of the number of changes gone into 10.2 by now (I'd
think, especially, the connection # output), there would be a large number
of failures if one'd use the 10.2 derbyTesting.jar with
10.1-client-10.2server testing. I assume that is why the
10.1 version derbyTesting.jar was picked.
But then, instead of only supporting the different clients, we'll also be
supporting different server versions in the test harness/test files...Which
would also possibly mean adding more code to an older version to support a
newer version.
It seems trivial now, but what about future versions? Like, 10.3 server and
10.1 client? We'll have to keep adding - hopefully minor - changes to the
10.1 test harness...Especially if we have canons, we may need to keep
modifying those canons both in multiple versions' derbyTesting.jars.
Hopefully I am worrying about nothing...but I do want to mention this
implication.
Myrna
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Kathey Marsden <km...@sbcglobal.net>.
Ramandeep Kaur wrote:
>Thanks to Kathey for looking into test failures.
>
>Attaching tmp and tmpstr files for autoGeneratedJdbc30 and holdCursorJDBC30.
>
>Please check out the attachments.
>
>
These do not look like compatibility problems.
holdCursorJDBC30 - Output changed with fix for DERBY-213
autoGeneratedJdbc30 matches the 10.2 master and looks like a changed output from the fix for DERBY-353.
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Ramandeep Kaur <ra...@gmail.com>.
Thanks to Kathey for looking into test failures.
Attaching tmp and tmpstr files for autoGeneratedJdbc30 and holdCursorJDBC30.
Please check out the attachments.
Thanks,
Raman (ramandhindsa@gmail.com)
On 1/16/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
> Ramandeep Kaur wrote:
>
> >Server: 10.2, Client: 10.1, derbyTesting.jar: 10.1
> >---------------------------------------------------------------------
> >jvms: jdk15, ibm142
> >
> >Test failures:
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:derbynet/NSinSameJVM.java
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/autoGeneratedJdbc30.java
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/procedure.java
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/syscat.sql
> >
> >
> >
> - autoGeneratedJdbc30. Can you send autoGeneratedJdbc30.tmp and tmpmstr
> files for further evaluation?
> - the rest look expected
>
> >Server: 10.1, Client: 10.2, derbyTesting.jar: 10.1
> >---------------------------------------------------------------------
> >jvms: jdk15, ibm142
> >
> > Test failures:
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java
>
> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java
> >
> >
> >
>
> - connectionJdbc20.java and LOBTest look problematic e.g
>
> > FAIL -- unexpected exception
> > SQLSTATE(null): org.apache.derby.client.am.SqlException: Stream of
> column value in result cannot be retrieved twice
> > org.apache.derby.client.am.SqlException: Stream of column value in
> result cannot be retrieved twice
> Test Failed.
> *** End: connectionJdbc20 jdk1.5.0_02 DerbyNetClient
> derbynetmats:jdbc20 2006-01-12 00:15:45 ***
>
> - forupdate and updatableResultSet are probably expected but it would
> be good if someone familiar with the updateable resultset work on 10.2
> could verify.
> - holdCursorJDBC30 Can you send the holdCursorJDBC30.tmp and tmpmstr
> files?
> - The rest look expected
>
>
> Thanks
>
> Kathey
>
>
>
Defining compatibility stability (was Re: Server and client
compatibility test for 10.2 and 10.1)
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Thanks for trackin these down, Dag.
So, I'm not sure how this works. We have made compatible changes in
terms of the API, but incompatible in terms of the output, particularly
of message strings. Is this considered a failure, and we are no longer
backward-compatible?
I agree we want to be backward-compatible, but do we need to apply the
same level of rigor to ij output format and error message strings as we
do to APIs?
At Sun we have a mechanism for declaring the stability of each interface
we present to users, where interfaces include but are not limited to:
- APIs
- command-line interface name and syntax
- stdout
- stderr
- error codes from command-line interfaces
- jar file names
- package names
- directory structure
- install location
- configuration file names
- configuration file syntax and format
- database file format
- transaction log file format
- error log file format
Each stability level implies a contract as to how and when an interface
can change (generally: it can change at a major release, at a minor
release, or at any time). Generally things like the API and CLI syntax
have a higher stability guarantee than say stderr or the error log format.
I think it might be worth our while to put up a Wiki page and identify
all our interfaces and the level of stability we want to have for them,
so we know what we should be testing for in terms of compatibility
between releases...
David
Dag H. Wanvik wrote:
> Hi,
>
>
>>>>>>"Kathey" == Kathey Marsden <km...@sbcglobal.net> wrote:
>
>
> Kathey> >Server: 10.1, Client: 10.2, derbyTesting.jar: 10.1
> Kathey> >---------------------------------------------------------------------
> Kathey> >jvms: jdk15, ibm142
> Kathey> >
> Kathey> > Test failures:
> Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
> Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
> Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
> Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql
> Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
> Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql
> Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java
> Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java
> Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java
>
> I have run this mixed release scenario (details below) and checked the
> results for:
>
> lang/forupdate.sql
> lang/updatableResultSet.java.
>
> In both cases, the differences are due to changes in the client, and
> thus expected. The changes are reflected in the current (10.2) client
> masters. Mostly, the diffs are changed exception messages, and in some
> cases, SQLStates.
>
> Dag
>
> ******* Start Suite: derbynetclientmats 2006-02-01 02:41:16 *******
> ------------------ Java Information ------------------
> Java Version: 1.5.0_04
> Java Vendor: Sun Microsystems Inc.
> Java home: /usr/local/java/jdk1.5.0_04/jre
> Java classpath: /home/dw136774/derby/trunk/jars/sane/derbyclient.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derby.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbytools.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbynet.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyTesting.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_de_DE.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_es.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_fr.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_it.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_ja_JP.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_ko_KR.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_pt_BR.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_zh_CN.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_zh_TW.j
ar:/home/dw136774/derby/trunk/tools/java/jakarta-oro-2.0.8.jar
> OS name: SunOS
> OS architecture: x86
> OS version: 5.10
> Java user name: dw136774
> Java user home: /home/dw136774
> Java user dir: /home/dw136774/derbytests/compat2
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.5
> --------- Derby Information --------
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [/home/dw136774/derby/trunk/jars/sane/derbyclient.jar] 10.2.0.0 alpha - (371922M)
> [/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derby.jar] 10.1.2.1 - (330608)
> [/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbytools.jar] 10.1.2.1 - (330608)
> [/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbynet.jar] 10.1.2.1 - (330608)
Re: Server and client compatibility test for 10.2 and 10.1
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
>>>>> "Kathey" == Kathey Marsden <km...@sbcglobal.net> wrote:
Kathey> >Server: 10.1, Client: 10.2, derbyTesting.jar: 10.1
Kathey> >---------------------------------------------------------------------
Kathey> >jvms: jdk15, ibm142
Kathey> >
Kathey> > Test failures:
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java
I have run this mixed release scenario (details below) and checked the
results for:
lang/forupdate.sql
lang/updatableResultSet.java.
In both cases, the differences are due to changes in the client, and
thus expected. The changes are reflected in the current (10.2) client
masters. Mostly, the diffs are changed exception messages, and in some
cases, SQLStates.
Dag
******* Start Suite: derbynetclientmats 2006-02-01 02:41:16 *******
------------------ Java Information ------------------
Java Version: 1.5.0_04
Java Vendor: Sun Microsystems Inc.
Java home: /usr/local/java/jdk1.5.0_04/jre
Java classpath: /home/dw136774/derby/trunk/jars/sane/derbyclient.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derby.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbytools.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbynet.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyTesting.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_de_DE.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_es.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_fr.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_it.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_ja_JP.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_ko_KR.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_pt_BR.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_zh_CN.jar:/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbyLocale_zh_TW.jar:/home/dw136774/derby/trunk/tools/java/jakarta-oro-2.0.8.jar
OS name: SunOS
OS architecture: x86
OS version: 5.10
Java user name: dw136774
Java user home: /home/dw136774
Java user dir: /home/dw136774/derbytests/compat2
java.specification.name: Java Platform API Specification
java.specification.version: 1.5
--------- Derby Information --------
JRE - JDBC: J2SE 5.0 - JDBC 3.0
[/home/dw136774/derby/trunk/jars/sane/derbyclient.jar] 10.2.0.0 alpha - (371922M)
[/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derby.jar] 10.1.2.1 - (330608)
[/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbytools.jar] 10.1.2.1 - (330608)
[/home/dw136774/derby-10.1/db-derby-10.1.2.1-lib/lib/derbynet.jar] 10.1.2.1 - (330608)
Re: Server and client compatibility test for 10.2 and 10.1
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi Kathey,
>>>>> "Kathey" == Kathey Marsden <km...@sbcglobal.net> wrote:
Kathey> >Server: 10.1, Client: 10.2, derbyTesting.jar: 10.1
Kathey> >---------------------------------------------------------------------
Kathey> >jvms: jdk15, ibm142
Kathey> >
Kathey> > Test failures:
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java
Kathey> >derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java
<snip>
Kathey> - forupdate and updatableResultSet are probably expected but it would
Kathey> be good if someone familiar with the updateable resultset work on 10.2
Kathey> could verify.
I'll have a look at this.
Dag
Re: Server and client compatibility test for 10.2 and 10.1
Posted by Kathey Marsden <km...@sbcglobal.net>.
Ramandeep Kaur wrote:
>Server: 10.2, Client: 10.1, derbyTesting.jar: 10.1
>---------------------------------------------------------------------
>jvms: jdk15, ibm142
>
>Test failures:
>derbynetclientmats/derbynetmats/derbynetmats.fail:derbynet/NSinSameJVM.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/autoGeneratedJdbc30.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:lang/procedure.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:lang/syscat.sql
>
>
>
- autoGeneratedJdbc30. Can you send autoGeneratedJdbc30.tmp and tmpmstr
files for further evaluation?
- the rest look expected
>Server: 10.1, Client: 10.2, derbyTesting.jar: 10.1
>---------------------------------------------------------------------
>jvms: jdk15, ibm142
>
> Test failures:
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql
>derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java
>derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java
>
>
>
- connectionJdbc20.java and LOBTest look problematic e.g
> FAIL -- unexpected exception
> SQLSTATE(null): org.apache.derby.client.am.SqlException: Stream of
column value in result cannot be retrieved twice
> org.apache.derby.client.am.SqlException: Stream of column value in
result cannot be retrieved twice
Test Failed.
*** End: connectionJdbc20 jdk1.5.0_02 DerbyNetClient
derbynetmats:jdbc20 2006-01-12 00:15:45 ***
- forupdate and updatableResultSet are probably expected but it would
be good if someone familiar with the updateable resultset work on 10.2
could verify.
- holdCursorJDBC30 Can you send the holdCursorJDBC30.tmp and tmpmstr
files?
- The rest look expected
Thanks
Kathey