I already have an issue open on the tracker to deal with some of the client semantics changes (https://github.com/seancribbs/ripple/issues/166); it might be broken out into separate issues so it can be completed.
Sean Cribbs <[email protected]> Developer Advocate Basho Technologies, Inc. http://basho.com/ On Jun 3, 2011, at 6:19 PM, Andrew Thompson wrote: > On Fri, Jun 03, 2011 at 06:08:06PM -0400, Keith Bennett wrote: >> 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? > > This is scary, it should not be possible to trigger this behaviour with > such a large gap. Even 10ms was enough to prevent it in my testing. >> >>>> >>> >>> 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. > > I suspect we will want to update the clients to support this, but I > don't know of a specific plan to do so yet. I don't know the details of > the ruby client enough (or at all) to advise on making changes to it. > >> >>> 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? >> > > git, not mercurial. I don't think we maintain the bitbucket repos > anymore, everything has moved to github. > > Andrew > > _______________________________________________ > 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
