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 "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2006/02/08 16:04:59 UTC
[jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
[ http://issues.apache.org/jira/browse/DERBY-934?page=comments#action_12365574 ]
Daniel John Debrunner commented on DERBY-934:
---------------------------------------------
Is this the plan for junit tests, to have a test directory per function, namely the 'sur' directory here?
junitTests/sur/SURTest.junit
If these tests were added under the old harness the correct location would be
tests/jdbcapi
The existing junitTests sub-directories are higher level than a set of functionality and two of the three match the exisitng harness layout, lang and bderyNet
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by Daniel John Debrunner <dj...@apache.org>.
Andreas Korneliussen wrote:
>> tests/jdbcapi
>>
>
> Or should it be tests/lang, since updatableResultSet.java (tests
> non-scrollable updatable results in the old harness) is located in
> tests/lang ?
No, the correct location is jdbcapi. This is functionality defined by
the JDBC spec, not by the SQL spec. The existing tests are in the
incorrect location.
Dan.
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by Andreas Korneliussen <An...@Sun.COM>.
Daniel John Debrunner (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-934?page=comments#action_12365574 ]
>
> Daniel John Debrunner commented on DERBY-934:
> ---------------------------------------------
>
> Is this the plan for junit tests, to have a test directory per function, namely the 'sur' directory here?
>
I did not find that the SUR tests naturally belongs in any of the
existing directories in junitTests, so I created a new package which is
descriptive for the type of tests. If someone finds a better package
name, I will gladly update it.
> junitTests/sur/SURTest.junit
>
> If these tests were added under the old harness the correct location would be
>
Note: I consider junit tests as a new test type which can be run under
the (old) harness, and which in the future can be run in another harness.
> tests/jdbcapi
>
Or should it be tests/lang, since updatableResultSet.java (tests
non-scrollable updatable results in the old harness) is located in
tests/lang ?
> The existing junitTests sub-directories are higher level than a set of functionality and two of the three match the exisitng harness layout, lang and bderyNet
>
True.
Andreas
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by John Embretsen <Jo...@Sun.COM>.
Wednesday, February 8, 2006, 8:41:20 PM CET, David W. Van Couvering wrote:
> It seems to me one quickly discovers that a test is junit-ified if it
> fails when you try to run it as a .java. It will also help that the
> suite files will describe it as a .junit.
Ah, I didn't think of the suite files. Thanks!
> To me this small annoyance is better than having to maintain two
> separate hierarchies and in some cases splitting up a coherent set of
> tests into two areas.
Sure, either way is fine with me once the new junit type is introduced.
> We could also write a tool that scans all the classes in a directory and
> reports which ones extend a JUnit class and which ones don't.
That's what I was hoping to avoid ;) Though I guess it's not that big of
an effort. Anyway, let's deal with that when the need arises. I guess it
will take quite some time until a large amount of the tests are
converted to type junit anyway...
--
John
> John Embretsen wrote:
>> Wednesday, February 8, 2006, 7:32:12 PM CET, David W. Van Couvering wrote:
>>
>>
>>>I am also a bit uncomfortable with a separate subdirectory for junit
>>>tests. Is there a specific reason for this segregation? If we have a
>>>new test type, .junit, why can't that be sufficient to distinguish
>>>between a JUnit test and an "old-style" test? I'd like to reuse the
>>>existing subdirectories like lang and jdbcapi rather than create a
>>>mirror of subdirectories, or even a completely orthogonal set of
>>>subdirectories, under junitTests.
>>
>>
>> Here is a link to a couple of messages to derby-dev regarding this
>> decision: http://tinyurl.com/bvde2 (Nabble)
>>
>> The reason for doing it this way was basically that at that time
>> (October last year), this was our best option with regards to separating
>> JUnit tests from other tests. Otherwise it may quickly become difficult
>> to keep track of which tests have been converted to (or created for)
>> JUnit.
>>
>> Does the new junit type really eliminate this "need"? The files are still
>> .java files; the type is just used by the harness to determine the java
>> executable it should use to run the test. Or am I missing something
>> here?
>>
>>
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
It seems to me one quickly discovers that a test is junit-ified if it
fails when you try to run it as a .java. It will also help that the
suite files will describe it as a .junit.
To me this small annoyance is better than having to maintain two
separate hierarchies and in some cases splitting up a coherent set of
tests into two areas.
We could also write a tool that scans all the classes in a directory and
reports which ones extend a JUnit class and which ones don't.
David
John Embretsen wrote:
> Wednesday, February 8, 2006, 7:32:12 PM CET, David W. Van Couvering wrote:
>
>
>>I am also a bit uncomfortable with a separate subdirectory for junit
>>tests. Is there a specific reason for this segregation? If we have a
>>new test type, .junit, why can't that be sufficient to distinguish
>>between a JUnit test and an "old-style" test? I'd like to reuse the
>>existing subdirectories like lang and jdbcapi rather than create a
>>mirror of subdirectories, or even a completely orthogonal set of
>>subdirectories, under junitTests.
>
>
> Here is a link to a couple of messages to derby-dev regarding this
> decision: http://tinyurl.com/bvde2 (Nabble)
>
> The reason for doing it this way was basically that at that time
> (October last year), this was our best option with regards to separating
> JUnit tests from other tests. Otherwise it may quickly become difficult
> to keep track of which tests have been converted to (or created for)
> JUnit.
>
> Does the new junit type really eliminate this "need"? The files are still
> .java files; the type is just used by the harness to determine the java
> executable it should use to run the test. Or am I missing something
> here?
>
>
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by John Embretsen <Jo...@Sun.COM>.
Wednesday, February 8, 2006, 7:32:12 PM CET, David W. Van Couvering wrote:
> I am also a bit uncomfortable with a separate subdirectory for junit
> tests. Is there a specific reason for this segregation? If we have a
> new test type, .junit, why can't that be sufficient to distinguish
> between a JUnit test and an "old-style" test? I'd like to reuse the
> existing subdirectories like lang and jdbcapi rather than create a
> mirror of subdirectories, or even a completely orthogonal set of
> subdirectories, under junitTests.
Here is a link to a couple of messages to derby-dev regarding this
decision: http://tinyurl.com/bvde2 (Nabble)
The reason for doing it this way was basically that at that time
(October last year), this was our best option with regards to separating
JUnit tests from other tests. Otherwise it may quickly become difficult
to keep track of which tests have been converted to (or created for)
JUnit.
Does the new junit type really eliminate this "need"? The files are still
.java files; the type is just used by the harness to determine the java
executable it should use to run the test. Or am I missing something
here?
--
John
> Daniel John Debrunner (JIRA) wrote:
>> [ http://issues.apache.org/jira/browse/DERBY-934?page=comments#action_12365574 ]
>>
>> Daniel John Debrunner commented on DERBY-934:
>> ---------------------------------------------
>>
>> Is this the plan for junit tests, to have a test directory per function, namely the 'sur' directory here?
>>
>> junitTests/sur/SURTest.junit
>>
>> If these tests were added under the old harness the correct location would be
>>
>> tests/jdbcapi
>>
>> The existing junitTests sub-directories are higher level than a set of functionality and two of the three match the exisitng harness layout, lang and bderyNet
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by Andreas Korneliussen <An...@Sun.COM>.
Myrna van Lunteren wrote:
> When - I think Rick - made the first junit test, I suggested a different
> directory for it.
>
> I was thinking of a future time, when the current test harness would be
> completely replaced by a junit-based framework. In that rosy future, all
> 'converted', and any 'new' tests would be junit based, until finally,
> nothing worthwhile remained under the current
> <trunk>/java/testing/org/apache/derbyTesting/functionTests dir.
> In that scenario, I was thinking the junit tests, and presumably some
> sort of framework/harness for gathering totals etc. to show up under
> <trunk>/java/testing/org/apache/derbyTesting/junitTests/...
> With comparable directory structure as is currently under functionTests.
>
> This is not where the tests junit tests ended up. As it is now, we might
> as well put them in their logical place under functionTests/tests.
>
I think the general feedback I get is that it is OK to put the junit
SUR-tests into: ../functionTests/tests/jdbcapi, so I have therefore
updated the patch.
As far as I know, svn is capable of handling moving of repository files
(svn move), so if someone want to refactor the test hiearchy for junit
tests in the future, they could do so while keeping the history of the
junit tests. Of course, getting it perfect the first time would have
been preferrable.
-- Andreas
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for Scrollable Updatable Resultsets
Posted by Myrna van Lunteren <m....@gmail.com>.
When - I think Rick - made the first junit test, I suggested a different
directory for it.
I was thinking of a future time, when the current test harness would be
completely replaced by a junit-based framework. In that rosy future, all
'converted', and any 'new' tests would be junit based, until finally,
nothing worthwhile remained under the current
<trunk>/java/testing/org/apache/derbyTesting/functionTests dir.
In that scenario, I was thinking the junit tests, and presumably some
sort of framework/harness for gathering totals etc. to show up under
<trunk>/java/testing/org/apache/derbyTesting/junitTests/...
With comparable directory structure as is currently under functionTests.
This is not where the tests junit tests ended up. As it is now, we might as
well put them in their logical place under functionTests/tests.
Myrna
On 2/8/06, Andreas Korneliussen <An...@sun.com> wrote:
>
> Hi all,
> Thanks for reviewing the patch.
>
> The junitTest directory was not introduced as part of this patch. it had
> been introduced from before, and all (3-4) junit tests are in that
> subdirectory.
>
> However I agree that it is not necessary to have a separate tree for
> JUnit type tests - so what should I do ?
> a, put the new tests into the tests/jdbcapi directory
> b, put them into a new directory : tests/junitTest/jdbcapi
>
> If I go for a, the existing junit tests should then also be moved.
>
> Either way is fine with me.
>
> --Andreas
>
> David W. Van Couvering wrote:
>
> > I am also a bit uncomfortable with a separate subdirectory for junit
> > tests. Is there a specific reason for this segregation? If we have a
> > new test type, .junit, why can't that be sufficient to distinguish
> > between a JUnit test and an "old-style" test? I'd like to reuse the
> > existing subdirectories like lang and jdbcapi rather than create a
> > mirror of subdirectories, or even a completely orthogonal set of
> > subdirectories, under junitTests.
> >
> > David
> >
> > Daniel John Debrunner (JIRA) wrote:
> >
> >> [
> >>
> http://issues.apache.org/jira/browse/DERBY-934?page=comments#action_12365574
> >> ]
> >> Daniel John Debrunner commented on DERBY-934:
> >> ---------------------------------------------
> >>
> >> Is this the plan for junit tests, to have a test directory per
> >> function, namely the 'sur' directory here?
> >>
> >> junitTests/sur/SURTest.junit
> >> If these tests were added under the old harness the correct location
> >> would be
> >>
> >> tests/jdbcapi
> >>
> >> The existing junitTests sub-directories are higher level than a set
> >> of functionality and two of the three match the exisitng harness
> >> layout, lang and bderyNet
> >>
> >>
> >>
> >>
> >>> 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
> >>
> >>
> >>
>
>
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by Andreas Korneliussen <An...@Sun.COM>.
David W. Van Couvering wrote:
> I would say you could put the new tests into the tests/jdbcapi directory
> and log a JIRA to move over the other tests, rather than try and swallow
> that into your patch, that's too much for one patch.
>
> David
Yes, I agree, it should go in different patches.
Andreas
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I would say you could put the new tests into the tests/jdbcapi directory
and log a JIRA to move over the other tests, rather than try and swallow
that into your patch, that's too much for one patch.
David
Andreas Korneliussen wrote:
> Hi all,
> Thanks for reviewing the patch.
>
> The junitTest directory was not introduced as part of this patch. it had
> been introduced from before, and all (3-4) junit tests are in that
> subdirectory.
>
> However I agree that it is not necessary to have a separate tree for
> JUnit type tests - so what should I do ?
> a, put the new tests into the tests/jdbcapi directory
> b, put them into a new directory : tests/junitTest/jdbcapi
>
> If I go for a, the existing junit tests should then also be moved.
>
> Either way is fine with me.
>
> --Andreas
>
> David W. Van Couvering wrote:
>
>> I am also a bit uncomfortable with a separate subdirectory for junit
>> tests. Is there a specific reason for this segregation? If we have a
>> new test type, .junit, why can't that be sufficient to distinguish
>> between a JUnit test and an "old-style" test? I'd like to reuse the
>> existing subdirectories like lang and jdbcapi rather than create a
>> mirror of subdirectories, or even a completely orthogonal set of
>> subdirectories, under junitTests.
>>
>> David
>>
>> Daniel John Debrunner (JIRA) wrote:
>>
>>> [
>>> http://issues.apache.org/jira/browse/DERBY-934?page=comments#action_12365574
>>> ]
>>> Daniel John Debrunner commented on DERBY-934:
>>> ---------------------------------------------
>>>
>>> Is this the plan for junit tests, to have a test directory per
>>> function, namely the 'sur' directory here?
>>>
>>> junitTests/sur/SURTest.junit
>>> If these tests were added under the old harness the correct location
>>> would be
>>>
>>> tests/jdbcapi
>>>
>>> The existing junitTests sub-directories are higher level than a set
>>> of functionality and two of the three match the exisitng harness
>>> layout, lang and bderyNet
>>>
>>>
>>>
>>>
>>>> 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
>>>
>>>
>>>
>>>
>
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by Andreas Korneliussen <An...@Sun.COM>.
Hi all,
Thanks for reviewing the patch.
The junitTest directory was not introduced as part of this patch. it had
been introduced from before, and all (3-4) junit tests are in that
subdirectory.
However I agree that it is not necessary to have a separate tree for
JUnit type tests - so what should I do ?
a, put the new tests into the tests/jdbcapi directory
b, put them into a new directory : tests/junitTest/jdbcapi
If I go for a, the existing junit tests should then also be moved.
Either way is fine with me.
--Andreas
David W. Van Couvering wrote:
> I am also a bit uncomfortable with a separate subdirectory for junit
> tests. Is there a specific reason for this segregation? If we have a
> new test type, .junit, why can't that be sufficient to distinguish
> between a JUnit test and an "old-style" test? I'd like to reuse the
> existing subdirectories like lang and jdbcapi rather than create a
> mirror of subdirectories, or even a completely orthogonal set of
> subdirectories, under junitTests.
>
> David
>
> Daniel John Debrunner (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/DERBY-934?page=comments#action_12365574
>> ]
>> Daniel John Debrunner commented on DERBY-934:
>> ---------------------------------------------
>>
>> Is this the plan for junit tests, to have a test directory per
>> function, namely the 'sur' directory here?
>>
>> junitTests/sur/SURTest.junit
>> If these tests were added under the old harness the correct location
>> would be
>>
>> tests/jdbcapi
>>
>> The existing junitTests sub-directories are higher level than a set
>> of functionality and two of the three match the exisitng harness
>> layout, lang and bderyNet
>>
>>
>>
>>
>>> 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
>>
>>
>>
Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for
Scrollable Updatable Resultsets
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I am also a bit uncomfortable with a separate subdirectory for junit
tests. Is there a specific reason for this segregation? If we have a
new test type, .junit, why can't that be sufficient to distinguish
between a JUnit test and an "old-style" test? I'd like to reuse the
existing subdirectories like lang and jdbcapi rather than create a
mirror of subdirectories, or even a completely orthogonal set of
subdirectories, under junitTests.
David
Daniel John Debrunner (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-934?page=comments#action_12365574 ]
>
> Daniel John Debrunner commented on DERBY-934:
> ---------------------------------------------
>
> Is this the plan for junit tests, to have a test directory per function, namely the 'sur' directory here?
>
> junitTests/sur/SURTest.junit
>
> If these tests were added under the old harness the correct location would be
>
> tests/jdbcapi
>
> The existing junitTests sub-directories are higher level than a set of functionality and two of the three match the exisitng harness layout, lang and bderyNet
>
>
>
>
>>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
>
>