db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-934) create a set of JUnit tests for Scrollable Updatable Resultsets
Date Fri, 10 Feb 2006 01:34:26 GMT
Hi, Andreas, here are my first set of comments on this patch.  More to 
come, I'm out of time for now.  These comments are replicated as a 
comment on the JIRA item as well...

========

Very nice tests, Andreas, well written and clear, easy to read and 
understand.

Here are some comments after my review:

- Your copyrights should just be "2006", not "1997, 2006". These files 
didn't originate in 1997 (did they?) :)

- In your negative tests, I think it's dangerous that *any* SQLException 
indicates a success. This will basically swallow any unexpected 
exceptions. I wouldl like to see the tests look for the specific SQL 
States that cause the expected exception.

- Can you explain in a comment why the default isolation level folr the 
SUR tests to REPEATABLE READ, given that that's not the default for Derby?

- Can you explain why you create a statement with CONCUR_UPDATABLE, and 
then later check the result set generated by that statement to make sure 
it's updatable? Wouldn't it always be? I'm sure this is just details of 
scrollable cursors that I am unaware of...

- You might want to explain at the top of the SURQueryMixTest class that 
it is a *suite* of tests, that's not obvious until you read all the way 
through it.

- It's an odd style in SURQueryMixTest.suite() to have mutiple statement 
blocks to get local scope of variables. Why not just declare the 
variables once and reuse them?

- Can you explain why all the concurrency tests use REPEATABLE READ 
isolation level?

- In testConcurrency7(), why do you need to explicitly purge the deleted 
rows by compressing the table? It would be great if you could explain 
this in your comments.

- In testConcurrency7(), why are you printing a stack track before 
rethrowing exceptions after updateRow()? Shouldn't the test framework 
print the stack trace for you?


Andreas Korneliussen (JIRA) wrote:
>      [ http://issues.apache.org/jira/browse/DERBY-934?page=all ]
> 
> Andreas Korneliussen updated DERBY-934:
> ---------------------------------------
> 
>     Attachment:     (was: DERBY-934.stat)
> 
> 
>>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
> 
> 

Mime
View raw message