Thanks all for your help. To perform my workflow properly, the
`return_head` option was precisely what I needed. Now I can do something
like
X = Initial Object
{ok, X1} = riakc_pb_socket(Pid, X, [return_head]).
X2 = riakc_obj:update_value(X1, NextValue).
{ok, X3} = riakc_pb_socket(Pid, X2, [return_head]).
And the above will generate no siblings. I was concerned more about
efficiency if using `return_body` but this works just fine.
Cheers,
Jeremy
On Wed, May 15, 2013 at 7:41 AM, Brian Roach <[email protected]> wrote:
> 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
