Jared - Thanks! I ran 'make rel', and got several errors like this:
fatal: Not a git repository (or any of the parent directories): .git The entire output is at https://gist.github.com/1011164. !!! However, the good news is that the build apparently succeeded, and the bug I reported before is no longer there!!! - Keith On Jun 6, 2011, at 5:10 PM, Jared Morrow wrote: > Keith, > > You can build for OSX using the source tarball for 0.14.2. There are plans > in the future to create packages for OSX once again. It is currently > planned for our next major release. > > -Jared > > On Mon, Jun 6, 2011 at 10:19 AM, Keith Bennett > <keith.benn...@lmnsolutions.com> wrote: > Sean and All - > > In case it helps, the problem manifested on riak 0.14.0 on Mac OS but not on > an Ubuntu VM. > > The most recent version available for download at > http://downloads.basho.com/riak/CURRENT/ for Mac OS was 0.14.0, so that's > what I'm using. I realize that would have been helpful information I could > have provided before, and apologize for not mentioning it -- I forgot that I > had to use an earlier version to run it on the Mac. Are there any plans to > provide more recent versions for the Mac? Or can I build from one of the > other packages? > > Also, Is there a way within Riak::Client or somewhere else in the ruby riak > client gem or riak executables or config files to get the server version > number and possibly OS information? I do see this: > > { % }: ls -1 releases > > 6.Jun.11 12.18 > 0.14.0 > start_erl.data > > ...is this the best way? > > Thanks, > Keith > > On Jun 4, 2011, at 11:26 AM, Sean Cribbs wrote: > > > 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 <s...@basho.com> > > 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 riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
