[
https://issues.apache.org/jira/browse/DERBY-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215049#comment-13215049
]
Mike Matrigali commented on DERBY-5382:
---------------------------------------
comments on reviewing latest patch. This change is definitely an improvement,
but still does not match what the original test
was doing. The best case would be if this test created a new database in the
first forked call and did the work below, then the
exact work would be tested. But not sure if current harness can do that. I
would suggest first making the changes below and
checking in, then work on executing in a separate db. Maybe others can help
with the separate db issue. If you don't want to deal
with comment issues, let me know and I can add some after you check in - i
don't want to conflict at this point.
In the original test the following actions are performed in oc_rec1, and then a
hard ("non clean shutdown") is performed.
beginTest(conn, test_name);
createAndLoadTable(conn, true, table_name, 5000, 0);
executeQuery(conn, "delete from " + table_name, true);
callCompress(conn, "APP", table_name, true, true, true, true);
endTest(conn, test_name);
The important part of this is that the create, delete, and compress log records
will all be processed by restart recovery when oc_rec2
is executed. And also of interest is all the work to create the database also
is in the log of unclean shutdown, this also presents
interesting code paths for restart recovery.
In the current patch the createAndLoadTable(tableName, true, 5000, 0) is done
and then a clean shutdown.
If you can't figure out a way to have a new database created in the forked
process, then please log an issue for adding harness support
for that, as it would be good to be able to test restart recovery on a newly
created db.
As a good incremental work around for your test I would move the
createAndLoadTable(tableName, true, 5000, 0); call from
testOCRecovery_1() to launchOCRecovery_1(). This still will not result in the
same codepaths tested, but it will be closer. Maybe add
in a extra create table of some dummy table, to make the session not read only.
At least
the clean shutdown with no work will lay down a checkpoint and make it less
likely that dependent on previous tests that a checkpoint
might happen during one of the phases and then we would skip the restart
recovery work that we are trying to test.
launchOCRecovery_2() is missing a few comments that are in oc_rec2()
comment in launchOCRecovery_3() is wrong (it was wrong in orignal also)
// setup to test redo recovery on:
// add more rows, delete rows, compress, add more, no commit
It should be:
// setup to test redo recovery on:
// add more rows, delete rows, commit, compress, no commit
launchOCRecovery_4 is missing comments from oc_rec4
> Convert existing harness recovery tests to JUnit tests
> ------------------------------------------------------
>
> Key: DERBY-5382
> URL: https://issues.apache.org/jira/browse/DERBY-5382
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Reporter: Siddharth Srivastava
> Assignee: Siddharth Srivastava
> Fix For: 10.9.0.0
>
> Attachments: DERBY-5382.diff, d5382.patch
>
>
> Existing harness recovery tests need to be converted to JUnit tests. A
> framework as designed in Derby-4249 can be used for this purpose.
> Tests to be converted:
> a) oc_rec1
> b) oc_rec2
> c) oc_rec3
> d) oc_rec4
> These recovery tests run in coordination. The test oc_rec1 creates a table,
> inserts and then deletes rows from it and commit it which is followed by a
> series of insertion of rows in the existing table in oc_rec2, oc_rec3 and
> oc_rec4. The tests oc_rec2 and oc_3 also create table and insert, delete,
> compress rows in it and leave the table thus produced in committed or
> uncommitted state which is tested by the next corresponding test (oc_rec3 for
> oc_rec2, oc_rec4 for oc_rec3) for recovery.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
