Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 10 Feb 2006 08:10:06 -0800
From: "David W. Van Couvering" <David.Vancouvering@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
 Scrollable Updatable Resultsets
In-reply-to: <43EC576E.8030405@sun.com>
To: derby-dev@db.apache.org
Message-id: <43ECBADE.4070907@sun.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_HdB9603/dPz4Gg1XsM3lMg)"
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
References: <1724693167.1139548742492.JavaMail.jira@ajax.apache.org>
 <43EC576E.8030405@sun.com>

This is a multi-part message in MIME format.

--Boundary_(ID_HdB9603/dPz4Gg1XsM3lMg)
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT

Well, it would probably be more work if you submitted them all at once 
and only one committer took a look at it.  I was thinking more that over 
the time it took you to *write* the tests, you would submit them 
incrementally.  So, in week one submit the junit test type with a basic 
test, week two submit the concurrency tests, week three submit the sur 
query mix tests and week four submit the surtest.  Weekly submissions 
rather than a Big Bang at the end when you're done.

David

Andreas Korneliussen wrote:
> David Van Couvering (JIRA) wrote:
> 
>>     [ 
>> http://issues.apache.org/jira/browse/DERBY-934?page=comments#action_12365844 
>> ]
>> David Van Couvering commented on DERBY-934:
>> -------------------------------------------
>>
>> One final comment: that was a *lot* of code to review in one go.  In 
>> the future it would be great if you could submit this in smaller, more 
>> manageable chunks.  It will ensure a better, closer review and won't 
>> cause "review fatigue" on us poor committers.
>>
> 
> Hi David,
> Thank you very much for the hard work of reviewing all my patches. I am 
> going through your comments and will update the patch today.
> 
> I did think this patch would be fairly managable, since it consist of 
> new files only, however I could of course have splitted it into three 
> patches, one for concurrency tests, one for sur query mix and one for 
> the surtest.  Wouldn't that just be more work  for both the committer 
> and developer ?
> 
> 
> --Andreas
> 
>> David
>>
>>
>>> create a set of JUnit tests for Scrollable Updatable Resultsets
>>> ---------------------------------------------------------------
>>>
>>>         Key: DERBY-934
>>>         URL: http://issues.apache.org/jira/browse/DERBY-934
>>>     Project: Derby
>>>        Type: Sub-task
>>>  Components: Test
>>>    Reporter: Andreas Korneliussen
>>>    Assignee: Andreas Korneliussen
>>> Attachments: DERBY-934.diff, DERBY-934.stat
>>>
>>> Add a set of JUnit tests which tests the implementation for 
>>> Scrollable Updatable ResultSets.
>>> The following is a description of how the tests will be implemented:
>>> Data model in test:
>>> We use one table containing three int fields and one varchar(5000)
>>> field. Then we run the tests on a number of variants of this model:
>>> 1. None of the fields are indexed (no primary key, no secondary key)
>>> 2. One of the fields is indexed as primary key
>>> 3. One of the fields is indexed as primary key, another field is
>>>   indexed as secondary key
>>> 4. One field is indexed as secondary key
>>> (primary key is unique, secondary key is not unique)
>>> By having these variations in the data model, we cover a number of
>>> variations where the ScrollInsensitiveResultSet implementation uses
>>> different classes of source ResultSets, and the CurrentOfResultSet
>>> uses different classes of target and source ResultSet.
>>> The table can be created with the following fields:
>>> (id int, a int, b int, c varchar(5000))
>>> -
>>> Queries for testing SUR:
>>> Select conditions:
>>> * Full table scan
>>> SQL: SELECT * FROM T1
>>> * Full table scan with criteria on non-indexed field
>>> SQL: .. WHERE c like ?
>>> SQL: .. WHERE b > ?
>>> * Full table scan with criteria on indexed field
>>> SQL: .. WHERE id>a
>>> * SELECT on primary key conditionals:
>>> - Upper and lower bond criteria:
>>> SQL: .. WHERE ID>? and ID<?
>>> SQL: .. WHERE ID=? -- (Single tuple)
>>> * Nested queries:
>>> SQL: .. WHERE ID in (1,2,3,4) SQL: .. WHERE a  in (1,2,3,4) (Other 
>>> nested queries containing a table seems to not permit updates)
>>> * SELECT on secondary key conditionals:
>>> SQL: .. WHERE a>? and a<?
>>> SQL: .. WHERE a=?
>>> * Projections:
>>> SQL: SELECT id,a,b,c
>>> SQL: SELECT id,c,b,a
>>> SQL: SELECT id,c
>>> SQL: SELECT id,a
>>> SQL: SELECT a,b,c
>>> SQL: SELECT a,b
>>> SQL: SELECT a,c
>>> The test should generate queries with all combinations of the
>>> projection and select conditions, and then run a number of tests:
>>> - test navigiation
>>> - test updates + navigation
>>> - test deletes + navigation
>>> - check rowUpdated() and rowDeleted() fields
>>> Scrollability: All scroll-insensitive cursors should be checked for
>>> scrollability. Scrolling is tested by invoking: next(), previous(),
>>> beforeFirst(), afterLast(), absolute(), relative(),  isBeforeFirst(),
>>> isAfterLast(), isFirst(), isLast(),
>>> Updating a scrollable resultset: a ResultSets current row can be
>>> updated either by using updateXXX() + updateRow(), or by using
>>> a positioned update query.  All tests which updates row, will come in
>>> two variants covering both these cases.
>>> -
>>> Deleting rows in scrollable resultset also has two variants: one using
>>> a positioned update query, and one using deleteRow().
>>> -
>>> Special testcases:
>>> Test that you get a warning when specifying a query which is not
>>> updatable and concurrency mode CONCUR_UPDATABLE.
>>> Case 1: Query containing order by
>>> Case 2: Query containing a join
>>> Exceptions:
>>> Test that you get an exception when specifying update clause "FOR 
>>> UPDATE"
>>> along with a query which is not updatable.
>>> Cases:
>>> * Query containing order by
>>> * Query containing a join
>>> Test that you get an exception when attempting to update a ResultSet 
>>> which has been downgraded to a read only ResultSet due to the query 
>>> Cases:
>>> * Query contained a join
>>> * Query contained a read only update clause
>>> * Query contained a order by
>>> Test that you get an exception when attempting to update a ResultSet 
>>> which has concurrency mode CONCUR_READ_ONLY
>>>
>>> Concurrency tests:
>>> (ConcurrencyTest)
>>> Cases: * Test that update locks are downgraded to shared locks after
>>>  repositioning. (fails with derby)
>>> * Test that we can aquire a update lock even if the row is locked with
>>>  a shared lock.
>>> * Test that we can aquire a shared lock even if the row is locked with
>>>  an update lock.
>>> * Test that we do not get a concurrency problem when opening two
>>>  cursors as readonly.
>>> * Test what happens if you update a deleted and purged record
>>> * Test what happens if you update a deleted and purged record using
>>>  positioned update
>>> * Test what happens if you update a tuple which is deleted and then
>>>  reinserted.
>>> * Test what happens if you update a tuple which is deleted and then
>>>  reinserted with the exact same values
>>> * Test what happens if you update a tuple which has been modified by
>>>  another transaction.
>>> * Test that you cannot compress the table while the ResultSet is open,
>>>  and the transaction is open (for validity of RowLocation)
>>> * Test that you cannot purge a row if it is locked
>>> * Test that Derby set updatelock on current row when using
>>>  read-uncommitted
>>
>>
>>
> 

--Boundary_(ID_HdB9603/dPz4Gg1XsM3lMg)
Content-type: text/x-vcard; charset=utf-8; name=david.vancouvering.vcf
Content-transfer-encoding: BASE64
Content-disposition: attachment; filename=david.vancouvering.vcf

YmVnaW46dmNhcmQNCmZuOkRhdmlkIFcgVmFuIENvdXZlcmluZw0KbjpWYW4gQ291
dmVyaW5nO0RhdmlkIFcNCm9yZzpTdW4gTWljcm9zeXN0ZW1zLCBJbmMuO0RhdGFi
YXNlIFRlY2hub2xvZ3kgR3JvdXANCmVtYWlsO2ludGVybmV0OmRhdmlkLnZhbmNv
dXZlcmluZ0BzdW4uY29tDQp0aXRsZTpTZW5pb3IgU3RhZmYgU29mdHdhcmUgRW5n
aW5lZXINCnRlbDt3b3JrOjUxMC01NTAtNjgxOQ0KdGVsO2NlbGw6NTEwLTY4NC03
MjgxDQp4LW1vemlsbGEtaHRtbDpUUlVFDQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJk
DQoNCg==

--Boundary_(ID_HdB9603/dPz4Gg1XsM3lMg)--