Thanks for the kind words, Jeremiah. Jeremy, if you find anything that's wrong with that description of sibling behavior, please let me know. It's always possible I missed something important.
-John On Wednesday, May 15, 2013, Jeremiah Peschka wrote: > John Daily (@macintux) wrote a great blog post that covers sibling > behavior [1] > > In short, though, because you're supplying an older vector clock, and you > have allow_mult turned on, Riak makes the decision that since a vector > clock is present that conflicts with what's already on disk a sibling > should be created. > > As I understand it, the only way to write into Riak and not get siblings > is to set allow_mult to false - even leaving out vector clocks will lead to > siblings if allow_mult is true. Or so John Daily's chart claims. > > [1]: http://basho.com/riaks-config-behaviors-part-2/ > > --- > Jeremiah Peschka - Founder, Brent Ozar Unlimited > MCITP: SQL Server 2008, MVP > Cloudera Certified Developer for Apache Hadoop > > > On Tue, May 14, 2013 at 10:48 PM, Jeremy Ong > <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> > > wrote: > >> To clarify, I am using the erlang client. From the looks of it, the >> vector clock transition to the new value is opaque to the client so the >> only way to streamline this use case is to pass the `return_body` option >> (My use case is one read, many subsequent writes while updating in memory). >> >> In this case however, I already have the value in memory, so it seems >> inefficient to have to get the entire riakc_obj back when I really just >> need the metadata to construct the new object. Is this correct? >> >> >> On Tue, May 14, 2013 at 9:06 PM, Jeremy Ong >> <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> >> > wrote: >> >>> Suppose I have an object X. >>> >>> I make an update to X and store it as X1. I perform a put operation >>> using X1. >>> >>> The same client then makes a modification to X1 and stores it as X2. >>> Then, I perform a put operation using X2. >>> >>> This will create two siblings X1 and X2 if allow_mult is true. Is there >>> any way I can avoid this? To me, the vector clock should have incremented >>> once when transitioning from X to X1, then once more when transitioning >>> from X1 to X2. This way, I shouldn't need to issue a get before I have to >>> perform another write since my data is already in memory. >>> >>> I probably am misunderstanding something about vector clocks. Does >>> anybody care to clarify this? >>> >>> Thanks, >>> Jeremy >>> >> >> >> _______________________________________________ >> riak-users mailing list >> [email protected] <javascript:_e({}, 'cvml', >> '[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
