It seems to me that occasional tombstone siblings may occur in the case
where two clients fetch the same vclock and concurrently do a delete and a
put.
If this is the case, there appears to be no way to differentiate a sibling
which intentionally has no content from a tombstone. Is that correct?
On Oct 6, 2011 3:22 AM, "Roland Karlsson" <
roland.karls...@erlang-solutions.com> wrote:
> Hi,
>
> Look at the answers to my question "Delete takes 5 seconds in RIAK 1.0 ??"
>
> And I actually found that the tombstone seemed to be able to live forever.
>
> The tombstone is nearly treated as an existing object.
>
>
> /Roland
>
>
>
> ----- Original Message -----
> From: "Eric Moritz" <e...@themoritzfamily.com>
> To: "Jon Meredith" <jmered...@basho.com>
> Cc: riak-users@lists.basho.com
> Sent: Thursday, October 6, 2011 12:28:19 AM
> Subject: Re: empty sibling after a DELETE then PUT
>
> What I am trying to model is a concurrent DELETE and a concurrent PUT
> where both operations use the same source VClock. When I do a GET
> after those concurrent operations is an object with two siblings; One
> blank and one with the data.
>
> Is the reconciliation of those two values, the responsibility of the
> application and if so, do we need to treat empty bodies as tombstones?
>
> Thanks,
> Eric.
>
> On Wed, Oct 5, 2011 at 6:21 PM, Jon Meredith <jmered...@basho.com> wrote:
>> Hi Eric,
>> What you are seeing is probably a result of some changes we've made to
>> deletes. After you issue the DELETE, Riak creates a tombstone object
first
>> and then removes it. 1.0 now adds a delay of 3s by default. If you do a
>> get during that time you should see an X-Riak-Vclock line for the 404
>> message after the delete.
>> If you use that vclock with the put then the tombstone will be removed.
The
>> feature wasn't well publicized so has not made it into the clients yet.
>> There should be more info to follow on deletes soon. If you really want
>> the old behavior, add {delete_mode, immediate} to the riak_kv section of
>> your app.config
>> Jon Meredith
>> Basho Technologies.
>> On Wed, Oct 5, 2011 at 1:13 PM, Eric Moritz <e...@themoritzfamily.com>
>> wrote:
>>>
>>> If I enabled allow_multi on a bucket and do I DELETE followed by a PUT
>>> I am getting a 300 response with one sibling having the body of the
>>> PUT and a second sibling with an empty body. If that the expected
>>> behavior?
>>>
>>> I wrote a script that would start with a reconciled value. Get the
>>> VClock of the current value. Then do every permutation of a PUT with
>>> (Pv) and without (P) the VClock and a DELETE with (Dv) and without (D)
>>> the vClock and I see the following result:
>>>
>>> Pv Dv 404
>>> Dv Pv 300
>>> Pv D 404
>>> D Pv 300
>>>
>>> Is it expected that a delete creates a blank sibling like that and
>>> therefore we should treat empty body's as deleted?
>>>
>>> Thanks,
>>> Eric Moritz.
>>>
>>> _______________________________________________
>>> riak-users mailing list
>>> riak-users@lists.basho.com
>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
>
> _______________________________________________
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
> _______________________________________________
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
