On Fri, Jun 03, 2011 at 02:00:23PM -0700, Aphyr wrote:
> Riak can't use the vclock for conflict resolution on a fresh object,
> i.e. one without a vclock. Deletes are writes. You should use get or
> reload before writing to help Riak sequence your writes correctly.
>
> On top of this, Riak has some weirdness around very quick sequences
> of deletes/writes due, IIRC, to deletes not being tagged with a
> vector clock. I... think... this will be addressed in an upcoming
> release.
>
Ah, my favorite bug. This is indeed mostly solved on master by exposing
the vclocks for tombstones so they can be cleanly overwritten by the new
object rather than merged into a frankenobject that has the metadata of
the tombstone but the value of the new object (which is then subject to
real deletion).
So the fix for the issue was to add a new type of return value for a get
that finds a tombstone, {error, {deleted, Vclock}} instead of always
returning {error, notfound} on a true notfound or when a tombstone is
encountered.
An example of how to safely delete for all 3 APIs can be found at
https://gist.github.com/965376
Note the new deletedvclock option. The REST API will always use this
option on gets and will return a X-Riak-Vclock header along with any 404
that is actually a tombstone.
Some further reading can be found here:
https://issues.basho.com/show_bug.cgi?id=260
https://issues.basho.com/show_bug.cgi?id=555
So, long story short; either upgrade to master and use the deletedvclock
option or avoid doing rapid put/delete/put cycles.
Andrew
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
