hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M. C. Srivas" <mcsri...@gmail.com>
Subject Re: Delete client API.
Date Tue, 17 Jan 2012 16:13:03 GMT
Delete seems to be confusing in general. Here are some examples that make
me scratch my head (key is same in all the examples):

Example1:
----------------
1. insert Val3  with TS=3  at real time t1
2. insert Val5  with TS=5  at real time t2 > t1
3. <del>    at real time t3 > t2
4. insert  Val6  with TS=6  at real time  t4 > t3

What does a read return?  (I would expect  Val6, since it was done last).
But depending upon whether compaction happened or not between steps 3 and
4, I get either Val6 or  nothing.

Example 2:
-----------------
1. insert Val3  with TS=3  at real time t1
2. insert Val5  with TS=5  at real time t2 > t1
3. <del>  TS=6  at real time t3 > t2
4. insert  Val6  with TS=6  at real time  t4 > t3

Note the difference in step 3 is this time a TS was specified by the client.

What does a read return?  Again, I expect Val6 to be returned. But
depending upon what's going on, I seem to get either Val5 or Val6.




On Sun, Jan 15, 2012 at 7:21 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:

> There are some confusing parts about the Delete client API:
> 1. calling deleteFamily removes all prior column or columns markers
> without checking the TS.
> 2. delete{Column|Columns|Family} do not use the timestamp passed to Delete
> at construction time, but instead default to LATEST_TIMESTAMP.
>
>   Delete d = new Delete(R,T);
>   d.deleteFamily(CF);
>
> Does not do what you expect (won't use T for the family delete, but rather
> the current time).
>
> Neither does
>   d.deleteColumns(CF, C1, T2);
>   d.deleteFamily(CF, T1); // T1 < T2
>
>
> (the columns marker will be removed)
>
>
> #1 prevents Delete from adding a family marker F for time T1 and a
> column/columns marker for columns of F at T2 even if T2 > T1.
> #2 is just unexpected and different from what Put is doing.
>
> In HBASE-5205 I propose a simple patch to fix this.
>
> Since this is a (slight) API change, please provide feed back.
>
> Thanks.
>
> -- Lars
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message