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 <[email protected]> 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 <[email protected]>
> 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
>> [email protected]
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>

_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Reply via email to