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 <jer...@quarkgames.com> 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 <jer...@quarkgames.com> 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 > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
