[
https://issues.apache.org/jira/browse/DERBY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445102#comment-13445102
]
Rick Hillegas commented on DERBY-5213:
--------------------------------------
Hi Myrna,
It looks to me as though the test tackles both cases described on this JIRA.
I'm a little confused by the queries which are supposed to check that the table
has 1000 rows and 0 rows. It seems to me that the queries are only looking at
the last 2 rows in the table and are not really verifying what they claim to.
Maybe "select count(*) from truncable" would be a better query. Thanks.
> Write tests to verify the interaction of TRUNCATE TABLE and online backup
> -------------------------------------------------------------------------
>
> Key: DERBY-5213
> URL: https://issues.apache.org/jira/browse/DERBY-5213
> Project: Derby
> Issue Type: Task
> Components: SQL, Store
> Affects Versions: 10.9.1.0
> Reporter: Rick Hillegas
> Assignee: Myrna van Lunteren
> Attachments: DERBY_5213.diff_1
>
>
> An uncommitted TRUNCATE TABLE command does not block online backup. We should
> verify that the online and backed up databases are both in a consistent
> state. At a minimum, we should test the following:
> o uncommitted truncate table followed by online backup and then access the
> backup copy and access the table. should see the old data.
> o uncommitred truncate table, followed by online backup that keeps logs,
> then commit the truncate, and then access the table in the backup.
> For more information, please see this email thread:
> http://old.nabble.com/truncating-a-table-vs-online-backup-to31524933.html#a31524933
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
