db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: GSoC 2011 Proposal: Derby Test and Fix
Date Mon, 28 Mar 2011 15:44:48 GMT
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


Mime
View raw message