[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-05-05 Thread Tiago R. Espinha (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706110#action_12706110
 ] 

Tiago R. Espinha commented on DERBY-3839:
-

I tried Dag's suggestion of making the result set updatable but it didn't help. 
Both the repro and the actual test fail, even with the result set set as 
updatable.

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> derby-3839.patch, ReproHoldCursorBug.java, ReproHoldCursorBug.java, 
> ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-05-04 Thread Kathey Marsden (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705714#action_12705714
 ] 

Kathey Marsden commented on DERBY-3839:
---

Thanks Tiago for the patch.  The test looks good, but we need to add the new 
test to store._Suite and remove the old test from derbynetmats.runall, 
storemore.runall and j9derbynetmats.runall.

It might be cleanest to change the result set to be updatable as Dag suggests 
to get consistent client/embedded behavior and add a comment as to why this was 
done.


> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> derby-3839.patch, ReproHoldCursorBug.java, ReproHoldCursorBug.java, 
> ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-05-04 Thread Dag H. Wanvik (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705635#action_12705635
 ] 

Dag H. Wanvik commented on DERBY-3839:
--

Btw, making the result set updatable, makes the repro work correctly since this 
forces prefetching to be disabled.


> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> derby-3839.patch, ReproHoldCursorBug.java, ReproHoldCursorBug.java, 
> ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-05-04 Thread Dag H. Wanvik (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705633#action_12705633
 ] 

Dag H. Wanvik commented on DERBY-3839:
--

It seems in the client/Server case, a prefetch of rows is performed 
independently of setting derby.language.bulkFetchDefault, so the change is not 
seen. I think it acceptable
behavior that the client driver does some prefetching of its own. I tried 
calling st.setFetchSize(1) but it made no difference. That quantity is only 
considered a hint, though. If the app really cares about changes, it should 
make a new query.  Btw, Derby does not yet implement scrollable sensitive 
result sets.



> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> derby-3839.patch, ReproHoldCursorBug.java, ReproHoldCursorBug.java, 
> ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-29 Thread Kathey Marsden (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704345#action_12704345
 ] 

Kathey Marsden commented on DERBY-3839:
---

I think having a JDBC test for this is good as it has already brought to light 
a serious bug.  I think you should continue with the java test and work around 
the bug for now and put a comment referring that it should be changed once 
DERBY-4198 is fixed.

Then make  a separate small ScriptTest that just tests the ij specific syntax 
without all the rigorous testing of hold behavior, but just basic testing to 
make  the ij syntax works.


 

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> ReproHoldCursorBug.java, ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-29 Thread Tiago R. Espinha (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704343#action_12704343
 ] 

Tiago R. Espinha commented on DERBY-3839:
-

So can I simply switch this over to a ScriptTest under Lang?

If I get a green light, I'll get on it first thing tomorrow, since this issue 
will no longer be blocked.

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> ReproHoldCursorBug.java, ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-29 Thread Myrna van Lunteren (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704337#action_12704337
 ] 

Myrna van Lunteren commented on DERBY-3839:
---

As long as the constructs are tested in one place, it should suffice. Lang is 
probably more suitable for that then store, I don't think we'd need to test ij 
specifics in any test in the tests/store directory.


> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> ReproHoldCursorBug.java, ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-29 Thread Tiago R. Espinha (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704174#action_12704174
 ] 

Tiago R. Espinha commented on DERBY-3839:
-

This issue is currently blocked by DERBY-4198.

I was reading through the DERBY-3801 and Myrna says:
"I think you believe a ScriptTest is a 'tool' to convert the test to junit, and 
it may have started as a quick way to run certain .sql ways in junit, but it is 
currently the best way to execute the language constructs that are specific to 
ij.
Yes, we have in the charter to use only standard SQL, but there are some 
extensions that are specific to Derby and they have to be tested also.

Language clauses as "get cursor with hold", "next", "update where current of".
So, it's important to keep a test that verifies appropriate behavior when such 
things are used in ij. Thus, we *do* need a HoldCursorIJTest, but it should be 
extending ScriptTestCase."

Considering that this test does rely a lot on the GET CURSOR WITH HOLD and it 
has its share of UPDATE WHERE CURRENT OF, should this test be extending 
ScriptTest as well rather than a BaseJDBCTestCase?

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> ReproHoldCursorBug.java, ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-26 Thread Knut Anders Hatlen (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702918#action_12702918
 ] 

Knut Anders Hatlen commented on DERBY-3839:
---

The assert failure must be a bug, so it would be good to file a separate JIRA 
issue for it.

I was able to get the test to run without failures by replacing "for update of 
data" with "for update" (or by removing the entire FOR UPDATE clause). No idea 
why that should be necessary, though.

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> ReproHoldCursorBug.java, ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-26 Thread Tiago R. Espinha (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702914#action_12702914
 ] 

Tiago R. Espinha commented on DERBY-3839:
-

Oh you're right Knut, my bad. I am not much of a JDBC user so I end up missing 
on these little details...

Anyway, I did add the updateRow() call after the updateInt() and now I'm 
getting an even weirder error. It's even weirder that it is happening on such a 
small fixture...

I'm getting this on one of the drivers:
1) 
testReproduction(org.apache.derbyTesting.functionTests.tests.store.ReproHoldCursorBug)org.apache.derby.shared.common.sanity.AssertFailure:
 ASSERT FAILED statementContext is not expected to equal statementContexts[0]

(this one also blows the JVM away)

and this on the other:
2)testReproduction(org.apache.derbyTesting.functionTests.tests.store.ReproHoldCursorBug)java.sql.SQLException:
 DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: 
java.lang.NullPointerExceptionXJ001.U

Any ideas? This should be so simple...

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> ReproHoldCursorBug.java, ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-26 Thread Knut Anders Hatlen (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702904#action_12702904
 ] 

Knut Anders Hatlen commented on DERBY-3839:
---

Shouldn't there have been a call to ResultSet.updateRow()? I don't think the 
database will be updated if you only call updateInt() + commit().

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> ReproHoldCursorBug.java, ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-23 Thread Tiago R. Espinha (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702051#action_12702051
 ] 

Tiago R. Espinha commented on DERBY-3839:
-

After talking this over on IRC, Dag suggested something that fixed this issue.

This test is using the following parameters on the createStatement:
ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE and 
ResultSet.HOLD_CURSORS_OVER_COMMIT

After going through the ResultSet code, I found out that the 
checkForUpdatableResultSet() method (called upon the deleteRow() )  overrides 
any of the checks that it would do, unless the ResultSet is set as 
CONCUR_READ_ONLY. So, basically put, switching this parameter will make the 
repro pass.

I am still working on the actual test and at this point I decided that it would 
be a better option to create individual tables for each test.
(As suggested by Kathey here: http://tinyurl.com/dxozhb )

Finally, I am also opening a bug for the described behavior above.

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat, derby-3839.patch, 
> ReproHoldCursorBug.java
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-22 Thread Mamta A. Satoor (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701620#action_12701620
 ] 

Mamta A. Satoor commented on DERBY-3839:


Tiago, I think you can disregard that comment. I looked through the test and 
the patch and seems like the conversion is fine. From what I recall, I may have 
thought that all the tests in the junit need to use for update clause but I 
don't see the original test using for update clause for all the test cases 
either.

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2009-04-22 Thread Tiago R. Espinha (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701464#action_12701464
 ] 

Tiago R. Espinha commented on DERBY-3839:
-

Mamta said:
> 3)The converted junit test has fixture 
> testBasicBtreeScanForZeroRowsUpdateNonkeyfield. This test uses for update of 
> clause here but the some of the other tests didn't.

Mamta, you say that some of the other tests did not use the 'for update of' 
clause, but looking at holdCursorJDBC30.out it seems to me that all the tests 
on the Btree Scan For Zero Rows Update Nonkey (refer to line 328 of 
holdCursorJDBC30.out) do use 'for update of data'.

Am I missing something or were you talking about Junjie's patch not containing 
the said clause?

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Tiago R. Espinha
> Attachments: derby-3839-1.patch, derby-3839-1.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2008-08-26 Thread Junjie Peng (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625982#action_12625982
 ] 

Junjie Peng commented on DERBY-3839:


Hi, Mamta. Thanks for attention. I'm sorry to return lately  as not free these 
days. I will provide a new patch some time later.

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Junjie Peng
> Attachments: derby-3839-1.patch, derby-3839-1.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.

2008-08-24 Thread Mamta A. Satoor (JIRA)

[ 
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625255#action_12625255
 ] 

Mamta A. Satoor commented on DERBY-3839:


Junjie, thanks for picking this really long test for conversion. The conversion 
job has been done pretty well. I just have following comments. (the comments 
might look little scattered because I wrote them down as I went through each of 
the subtest conversion.)

1)The first thing the test does is set autocommit to false. Shouldn't each of 
the junit test fixture do the same?

2)In several places in the original test, it does close on resultset first and 
then commit but the converted junit test appears to do it in reverse order. 


3)The converted junit test has fixture 
testBasicBtreeScanForZeroRowsUpdateNonkeyfield. This test uses for update of 
clause here but the some of the other tests didn't.

4)The converted junit test has fixture 
testBasicBtreeScanTestsForMultipleRowsOrUpdateNonkeyField. It needs to define 
index like the earlier test stUtil.executeUpdate("create index foox on foo 
(a)"); This will match what the original non-junit test intended.

5)The following set of tests from original test are missing in the junit test. 
I think it could go in test fixutre  
testBasicBtreeScanTestsForMultipleRowsOrUpdateNonkeyField
ij> --  test negative case of trying non next operations after commit
get with hold cursor test1 as 
'select * from foo for update of data';
ij> next  test1;
A  |DATA   
---
1  |10 
ij> commit;
ij> delete from foo where current of test1;
ERROR 24000: Invalid cursor state - no current row.
ij> next  test1;
A  |DATA   
---
1  |20 
ij> commit;
ij> update foo set data=-3000 where current of test1;
ERROR 24000: Invalid cursor state - no current row.
ij> next  test1;
A  |DATA   
---
1  |30 
ij> next  test1;
A  |DATA   
---
1  |40 
ij> next  test1;
A  |DATA   
---
1  |50 
ij> next  test1;
No current row
ij> close test1;
ij> commit;
ij> -- should fail
next test1;
IJ ERROR: Unable to establish cursor

6)There is a test as follows in the original test
ij> --  make sure above deletes/updates worked.
get with hold cursor test1 as 
'select * from foo for update of data';
ij> next  test1;
A  |DATA   
---
1  |10 
ij> commit;
ij> next  test1;
A  |DATA   
---
1  |30 
ij> commit;
ij> next  test1;
A  |DATA   
---
1  |-3000 
The test above checks that update made earlier shows up. The converted test 
does not look for new value -3000. The converted test for above test is as 
below (it is in testBasicBtreeScanTestsForMultipleRowsOrUpdateNonkeyField)
+//make sure above deletes/updates worked.
+test1 = st.executeQuery("select * from foo for update of data");
+assertTrue(test1.next());
+assertEquals(1, test1.getRow());
+commit();
+assertTrue(test1.next());
+assertEquals(2, test1.getRow());
+commit();
+assertTrue(test1.next());
+assertEquals(3, test1.getRow());


7)The converted junit test has fixture 
testBasicBtreeScanTestsForMultipleRowsOrReadOnly. It should create an index on 
foo to match the original test.


8)There are several places in the test where it matters what was the exact row 
data retruned on a "next.." but the converted test always just checks for 
test1.getRow() rather than the actual row data. One of those examples would be 
Test 7, Test 8, Test 9. There might be other places in the test where we should 
look for the row data rather than row number.

> Convert 
> "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to 
> junit. 
> ---
>
> Key: DERBY-3839
> URL: https://issues.apache.org/jira/browse/DERBY-3839
> Project: Derby
>  Issue Type: Test
>  Components: Test
>Reporter: Junjie Peng
>Assignee: Junjie Peng
> Attachments: derby-3839-1.patch, derby-3839-1.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.