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
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
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
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
sho
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 c
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
