Aphyr & Andrew -
Thanks for your responses. I'm trying to wrap my head around the issues you
raised, and I must confess it's difficult. Anyway, some questions for you...
On Jun 3, 2011, at 5:12 PM, Andrew Thompson wrote:
> 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.
If the caller doesn't have a handle to the RObject in the Ruby framework, or
the metadata of an HTTP response, but is only accessing the data by bucket and
key values, is there any way to use reload? And if the object has been deleted
is there any way to use get?
>>
>> 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.
I tried inserting a 20 second pause between each read/write, but there was no
change in the behavior. Should it be longer than that?
>>
>
> 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.
>
That sounds like exactly what I need. Can I simulate that fix in my Ruby code?
Any pointers about that? Any chance we could get that into the Ruby client?
I'd be willing to put a little effort into that, but I don't really understand
the issues well enough yet.
> 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.
You're suggesting I use mercurial to pull down the HEAD and use that, right?
Thanks again,
Keith
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
