Jeremy - As noted in the other replies, yes, you need to use 'return_body' to get the new vector clock in order to avoid creating a sibling on a subsequent write of the same key.
That said, you can supply the param 'return_head` in the proplist along with `return_body` which will eliminate having the value returned to you and get the vclock you need. - Roach On Wed, May 15, 2013 at 8:23 AM, John Daily <[email protected]> wrote: > 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]> >> 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]> >>> 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] >>> 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 > _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
