On 3/28/2011 6:27 AM, siddharth srivastava wrote:
Hi
Following is my proposal for GSoC 2011 for the project Derby Test and
Fix: I request the community to pease provide your feedback and
suggestions for it.
Siddharth. I think your detailed proposal looks excellent. I would
propose the following additions:
Add an abstract section at the beginning that just identifies this as a
proposal for the Derby Test and Fix project with a goal of fixing bugs
and converting tests to JUnit.
Call out how much time you can commit per week this summer to GSoC and
if you have any other commitments or vacations planned this summer.
Add a section on your prior experience, what you have done already on
Derby, when you first joined the community, that you have your build and
test environment set up and what issues you have been working on
already. Mention the wiki updates you plan for making entering the
community easier for new developers. Also include languages and
relevant course work.
*Proposal:*
The proposal has been categorized in six phases as follows:
/1)Derby-5014: Tests should restore the timeout values to default
after they are done running./
The tests to be fixed in this issue:
1) ErrorMessageTest.java 2) StressMultiTest.java 3) Sttest.java 4)
SysinfoTest.java 5)DatabaseMetaDataTest.java 6)
ResultSetsFromPreparedStatementTest.java
In these tests, the timout values (deadlock timeout, wait timout) are
being changed when they start running , but they are not restored to
appropriate values once the test finishes running.
The issue primarily requires changing the callable statements to set
the properties with the help of DatabasePropertyTestSetup decorator.
The lock timeouts in the above tests can be adjusted with the help of
the function “setLockTimeouts (Test test, int deadlockTime, int
waitTime)” in the class DatabasePropertyTestSetup. The class
DatabasePropertyTestSetup, ensures that the old values of the
properties, if changed before execution, are restored after the
execution is over.
/2)Derby-4795: Starting network server with -ssl turns SSL off/
If no mode is specified while starting the network server with –ssl option
for example with “java -jar derbynet.jar start –ssl”, the SSL is
turned off.
Turning off ssl with an empty sslmode argument is unintuitive and is
susceptible to errors.
A better approach, in the absence of sslmode argument would be to
output an error and display the usage guidelines for sslmode such as:
Error<error-code> : Missing <sslmode> argument
Usage: -ssl <sslmode>
SSLMODE can be any of the following:
SSL_OFF: Turns off SSL. No SSL encryption would be used
SSL_BASIC: Use basic SSL Encryption
SSL_PEER_AUTHENTICATION: Use SSL Encryption with Peer Authentication
/3) Derby-4779: NPE while inserting into a table which has a generated
column and an insert trigger/
The problem in this issue seems to be due to an invalid result set.
The error originates from EmbedStatement.java where statement is
executed. The inability to process the resultset becomes more clear
with the error at GenericPreparedStatement.java:436 i.e. resultSet.open().
This propagates to the function getNextRowCore() in
InsertResultSet.java which expects the source resultset to return the
next row of the result set, which is required by the trigger to insert
the rows in the table “dummy” as per the repro attached with this
issue. As the row has not been obtained from the result set, it causes
a NullPointerException to occur and in consequence closes the connection.
/4)Derby-4249: Create a simple store recovery test in JUnit/
Derby tests are categorized into two categories: harness test and
JUnit test. The JUnit tests have the advantage that they can be run
using JUnit’s TestRunner without explicitly needing any command line
setup, the Test Suite class makes it easier to write and standardize
the writing of JUnit test cases, hence is the need of converting the
harness test cases to JUnit test cases.
The aim is to provide a basic framework which can be established as a
model for conversion of harness store recovery tests to JUnit.
The test would do the following:
(a) Connect, create a table, commit and shutdown the database.
(b) fork a jvm, add one row, commit, add another row, exit the jvm.
(c) Reconnect with the first jvm and verify that the first row is
there and the second is not.
This cycle would ensure that the database can recover from uncommitted
changes as well as that the committed changes become persistent.
5)DERBY-3676 : Make the toString() method of Derby PreparedStatements
print out SQL text with ? parameters replaced by the values that have
been set so far
This issue already has a lot of discussion and patches behind it. The
approach behind this phase would be to:
a)Study the existing patches and discuss with the community the
possible reasons due to which the patches were not committed.
b)Identify a way to execute a query against the virtual table with new
string representation. Also look into the possibility of modifications
to the statement cache virtual table implementation so as to maintain
the backward compatibility.
/6)Converting Recovery tests to JUnit (this doesn’t have a Jira issue
as of now)/
This issue would act as a follow up of Derby-4249 to convert existing
harness recovery tests to JUnit test using the model proposed in phase-4.
I plan to convert the following recovery tests to JUnit:
a)oc_rec1
b)oc_rec2
c)oc_rec3
d)oc_rec4
These recovery tests run in coordination. The test oc_rec1 creates a
table, inserts and then deletes rows from it and commit it which is
followed by a series of insertion of rows in the existing table in
oc_rec2, oc_rec3 and oc_rec4. The tests oc_rec2 and oc_3 also create
table and insert, delete, compress rows in it and leave the table thus
produced in committed or uncommitted state which is tested by the next
corresponding test (oc_rec3 for oc_rec2, oc_rec4 for oc_rec3) for
recovery.
The aim of this issue is to transform this behavior in JUnit using the
recovery model proposed in phase 4 of this proposal.
TENTATIVE TIMELINE:
Note: The proposal with detailed timeline is posted at my blog[1]
1) Derby 5014: Tests should restore the timeout values to default
after they are done running.
Timeline: May 22- 5th June 2011 (15 days)
2) Derby-4795: Starting network server with -ssl turns SSL off
Timeline: 6th June - 13th June 2011 ( 8 days)
3) Derby- 4779: NPE while inserting into a table which has a generated
column and an insert trigger
Timeline: : 14th June-26th June 2011 (15 days)
INTEGRATION TESTING PERIOD: June 27th - June 29th
4) Derby-4249:Create a simple store recovery test in JUnit
Timeline: 30th June- 19th July (20 days)
5) DERBY-3676 : Make the toString() method of Derby PreparedStatements
print out SQL text with ? parameters replaced by the values that have
been set so far
Timeline: 20th July- 2nd August (14 days)
6) Store Recovery test conversion
Timeline: 3rd August - 15th August ( 14 days)
[1] I have also made it available on this blog so that updating it
becomes easy:
http://siddharthsrivastava.blog.co.in/2011/03/28/gsoc-2011-derby-test-and-fix/
Thanks
Regards
Siddharth Srivastava
