[jira] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago R. Espinha updated DERBY-3839: Derby Info: [Patch Available] > 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, derby-3839.patch, derby-3839.stat, 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] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago R. Espinha updated DERBY-3839: Attachment: derby-3839.stat derby-3839.patch I'm attaching another patch. This one removes the test from the harness, adds it to the Suite and effectively removes the .sql and .out files from the system. It seems that Junjie's patch wasn't removing those files but just emptying them instead. I'm not sure we want to keep the empty files around so I just deleted them. If this isn't the desired behavior please let me know. > 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, derby-3839.patch, derby-3839.stat, 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] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago R. Espinha updated DERBY-3839: Attachment: derby-3839.patch This is a working patch of this test. I haven't yet ran suites.All nor derbyall but will do so if this patch is considered for committal. Keep in mind that this test has two workarounds: - It drops the 'FOR UPDATE' clause of some of the fixtures as they were causing crashes (on both embedded and client/server) - It has to separate behaviours (for embedded and client/server) on the tests testPositionPurgedRow and testPositionPurgedPage. Also, my last comment was wrong. It is the client driver's results that aren't faithful to those of the original test. As can be seen on the repro class I have attached, the underlying changes to a table aren't replicated to an already open cursor of that table. Is this by design? Considering it only happens on the client driver? > 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] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago R. Espinha updated DERBY-3839: Attachment: ReproHoldCursorBug.java I have run into what seems to be another bug. Initially I thought this could simply be a normal different behaviour between embedded and client drivers. Kathey has however suggested that it could be a bug so I'm posting it here to get some opinions. The issue is on the embedded driver. The problem happens when we create a cursor and while having it on a certain record, another statement is executed that deletes both the record that the cursor is on and the next one. If afterwards we advance the cursor, the embedded driver will act as if the rows haven't been deleted at all, whereas the client driver seems to behave correctly. It needs to be said though that the client driver will only pass as long as the bulkFetchDefault is set to 1. Any other values on this property seem to make the client error out as well. > 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, ReproHoldCursorBug.java > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago R. Espinha updated DERBY-3839: Attachment: ReproHoldCursorBug.java I am uploading a new version of my reproduction test. This time I think I might have found a different bug. The test as it is, is failing but it shouldn't. The problem seems to be that the updateInt() isn't persisting the changes into the database. The fail I get is: 1) testReproduction(org.apache.derbyTesting.functionTests.tests.store.ReproHoldCursorBug)junit.framework.AssertionFailedError: expected:<-3000> but was:<10> suggesting that the update isn't indeed being successful. No exceptions are thrown and no update is made, so I believe that either way there is something wrong going on here. > 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] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[
https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tiago R. Espinha updated DERBY-3839:
Attachment: ReproHoldCursorBug.java
This file is a repro test class that I'm uploading to sort out a behaviour that
I'm witnessing. This is either a bug or then I am most certainly missing
something.
This test should mimic the following behaviour:
--8<
call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.language.bulkFetchDefault',
'1');
create table foo4 (a int, data int);
insert into foo4 values (1,10);
insert into foo4 values (1,20);
insert into foo4 values (1,30);
insert into foo4 values (1,40);
insert into foo4 values (1,50);
get with hold cursor test1 as 'select * from foo4 for update of data';
next test1;
commit;
delete from foo4 where current of test1;
-- should fail
next test1;
commit;
update foo4 set data=-3000 where current of test1;
-- should fail
--8<
Both the update and the delete should fail because of the commit, and they do
if I follow those exact steps on ij. However, the JDBC test doesn't throw an
exception on the update and it reaches the fail() call.
The error that ij rightfully throws is ERROR 24000: Invalid cursor state - no
current row.
Any ideas?
> 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] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago R. Espinha updated DERBY-3839: Attachment: derby-3839.patch I went through Junjie's patch line-by-line and here's what I changed: - Added the 'for update' clause where it was missing, to mimic the original test. - Added the setAutoCommit(false) on the setUp() method. - Set the bulkFetch to 1 where it was missing, as per the original test. - Removed assertTrue(true) from the exceptions as I believe this is a waste of space and resources. - Checked the order of all the close() and commit() calls, so that it also mimics the original test (there were a few wrong ones as Mamta said). - Made the asserts so that we check the actual data in the tables rather than just the row number. Now, the problem is that when I run the test, I systematically get errors like "Table/View 'FOO' already exists in Schema 'APP'.". Ideally we'd create the tables on the decorator so that they'd be self-managed, but that isn't optimal as each test has its own requirement as far as tables go. Some require the tables to be empty, some require some records in it, and it is often the case that the tables are simply different. With this said, I kept Junjie's approach of creating and dropping the tables on each fixture. I must be doing something wrong though, as I keep hitting that error. Just to cover all possibilities, I added a commit() call after the dropTable is called but still no luck. I still get the same errors and I must be missing something. If anyone has any ideas, I'd appreciate it. > 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 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3839: --- Derby Info: (was: [Patch Available]) Clearing patch available flag, a new patch is expected 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] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Junjie Peng updated DERBY-3839: --- Derby Info: [Patch Available] > 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] Updated: (DERBY-3839) Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorJDBC30.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Junjie Peng updated DERBY-3839: --- Attachment: derby-3839-1.stat derby-3839-1.patch Please check the patch, thanks! > 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.
