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
