[
https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599976#comment-13599976
]
Anoop Sam John commented on HBASE-7801:
---------------------------------------
1. HBaseTestCase
{code}
- this.region.delete(delete, writeToWAL);
+ this.region.delete(delete);
{code}
Do we need to set SKIP_WAL/SYNC_WAL based on writeToWAL into Delete object?
2.TestFilter
{code}
Delete d = new Delete(ROW);
d.deleteColumns(FAMILIES[0], QUALIFIERS_ONE[1]);
d.deleteColumns(FAMILIES[1], QUALIFIERS_ONE[1]);
- this.region.delete(d, false);
+ this.region.delete(d);
{code}
Do we need to set SKIP_WAL into Delete object?
{code}
@@ -217,7 +218,7 @@
// create new rows and column family to show how reseek works..
for (byte[] ROW : ROWS_THREE) {
Put p = new Put(ROW);
- p.setWriteToWAL(true);
+ p.setWriteGuarantee(WriteGuarantee.SKIP_WAL);
{code}
Not SKIP_WAL but SYNC_WAL.
3.TestProtobufUtil
{code}
- assertEquals(true, proto.getWriteToWAL());
+ assertEquals(true, proto.getWriteGuarantee());
{code}
Assertion is wrong now. Test will fail. Other places also where assertEquals
related changes are there.
4.TestCompaction
{code}
- r.delete(new Delete(results.get(0).getRow()), false);
+ r.delete(new Delete(results.get(0).getRow()));
{code}
Do we need to set SKIP_WAL into Delete object?
5.TestGetClosestAtOrBefore
{code}
- mr.delete(new Delete(keys.get(0).getRow()), false);
+ mr.delete(new Delete(keys.get(0).getRow()));
{code}
Do we need to set SKIP_WAL into Delete object? And other similar places in this
file
6.TestHRegion
{code}
- region.delete(delete, false);
+ region.delete(delete);
{code}
Do we need to set SKIP_WAL into Delete object?
> Allow a deferred sync option per Mutation.
> ------------------------------------------
>
> Key: HBASE-7801
> URL: https://issues.apache.org/jira/browse/HBASE-7801
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 0.95.0, 0.94.6
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
> Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt,
> 7801-0.96-full-v2.txt, 7801-0.96-v1.txt
>
>
> Won't have time for parent. But a deferred sync option on a per operation
> basis comes up quite frequently.
> In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a
> special mutation attribute.
> For batch operation we'd take the safest sync option of any of the mutations.
> I.e. if there is at least one that wants to be flushed we'd sync the batch,
> if there's none of those but at least one that wants deferred flush we defer
> flush the batch, etc.
--
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
