gistfile1.txt

07:31 <nfo> Hi all. A question about conflict resolution and vclocks. How do I "mark" the conflict 
as fixed ? I update the content-type from 'multipart/mixed' to the original one, 
I update the object data. But what  about the vclock ? If a lot of conflicts happened before 
I fixed it, the vclock could be big.  Do I have to generate one  on the client side as soon as 
I fixed the conflict ? 

07:32 <nfo> I get lost here because I read that I'm suppose to put objects with the same vclock 
than the one returned by riak 

07:32 <seancribbs> nfo: you send the vclock that was sent with both siblings 

07:33 <seancribbs> riak has already calculated the merged vclock for you 

07:35 <seancribbs> it may create another conflict, but if every write creates conflicts, 
you probably need to consider some other storage model than just flipping on allow_mult 

07:37 <nfo> seancribbs: haha, yeah, I could have been in a race condition lately 

07:37 <seancribbs> sometimes a write-only model can work 

07:38 <seancribbs> i.e. always write new objects, compute the real result with map-reduce 

07:38 <nfo> seancribbs: ok, so I see that the siblings have all the same vclock. In my 
current code, I put the vclock of the main object; is it problematic ? Does riak understand it ? 
Or the problem is just that  the vclock becomes too big ? 

07:38 <seancribbs> riak understands it 

07:39 <nfo> ok, so that's why I created a 400MB with 280k conflicts :) 

07:39 <seancribbs> eek 

07:39 <nfo> with 10 ruby processes, I was a little ... surprised.. 

07:40 <seancribbs> well hmm 

07:40 <seancribbs> so, are they all trying to resolve the same object? 

07:40 <nfo> this vclock bug (on my side) could have generate this problem ? 

07:40 <nfo> yeah, they update an array in the same object from time to time 
07:41 <seancribbs> ok 


07:41 <nfo> or it could be a bad vclock + race condition problem ? 

07:41 <seancribbs> well, so if you *ever* send a stale vclock with allow_mult turned on, 
it'll create a sibling 

07:42 <nfo> understood. Then let's see what happens when I set the right vclock :) 

07:42 <seancribbs> heh 

07:42 <nfo> to resolve a conflict, my code does that: update the content type, replace the data, and 
set the vclock. Is that ok ? 

07:43 <seancribbs> don't set the vclock, just send back the one riak gave you 

07:43 <seancribbs> i.e. don't touch it 

07:44 <seancribbs> so what you might want to do is take the first sibling object and send that 
back with the updated data 

07:44 <seancribbs> (i'm assuming this is ruby) 

07:44 <nfo> yeah, riak-client 

07:44 <nfo> making a pastie 

07:45 <nfo> ok, updating my code and then making a pastie :) Right now, 
I try to update the main object instead of the first sibling 

07:45 <nfo> so ok, I won't have to update @conflict, the content type and the vclock 

07:46 <seancribbs> nope 

07:47 <nfo> *ashamed* 

07:47 <seancribbs> why? 

07:49 <nfo> just because I'm pretty sure I read that somewhere 

07:49 <seancribbs> happens to the best of us 

08:20 <nfo> seancribbs: is it possible that siblings have the same vclock as 
the multipart object ? 

08:20 <nfo> s/as/than 

08:20 <seancribbs> nfo: they exactly do 

08:20 <seancribbs> so, internally they don't 

08:20 <seancribbs> but to the client they do 

08:21 <seancribbs> because really, it's a single object, with multiple values 

08:21 <seancribbs> so in the simple case of "pick one value over the other", you just 
have to pick that one and store it 

08:22 <nfo> I understood earlier that the clock of the main object was a "conflicted one", 
whereas the vclock of siblings was the "i resolved the conflict one" 

08:22 <seancribbs> no… sorry I didn't make that clear. 

08:22 <seancribbs> They are the same vclock 

08:23 <seancribbs> if you think of a vclock as a point in time, it makes more sense. 
"this is the point in time where I merged these siblings" 

08:23 <seancribbs> the subsequent vector clock is the resolved version 

08:24 <nfo> ok, get it. So, according to what I read in the vector clock blog articles, 
the vector clock will grow and grow after each conflict ? 

08:24 <seancribbs> nfo: until it has been pruned, yes 

08:24 <seancribbs> so… after a time of no conflicts 

08:25 <nfo> seancribbs: you mean that "pruning" the vclocks is automatically done by Riak ? 

08:26 <seancribbs> nfo: yes