>
> As for what semantics Riak supports, I understand what it supports.
> It just seems to me like it wouldn't take a lot to make it support a
> lot more.
>
That's where I disagree with you. We have tried to make Riak's current model as
rock-solid as possible, and we're still improving it, but
The idea of keeping change events inside of an object was one I had
not fully thought through. I think that is doable.
I'd thought about having independently written objects for a history.
But was looking at how to make the update to the root of the history
be as close to atomic as possible. Lik
To save other people the effort of watching a reasonably long video,
it demonstrates how to show the conflict to the user. In the
application where it is done (a wiki) it is an entirely appropriate
UI.
On Mon, Apr 18, 2011 at 9:01 PM, Eric Moritz wrote:
> Ben,
>
> There's a little demo app that
On Apr 18, 2011, at 7:46 PM, Ben Tilly wrote:
>> Given the non-atomic nature of reads and writes in Riak, it is likely
>> that neither of the two clients that wrote that data was in any way
>> aware of the existence of the other write. This makes your suggestion
>> of escalating to the user impos
Ben,
There's a little demo app that was written by someone at Basho that
demostrates a way to accomplish what you're talking about.
http://forms.basho.com/riak-in-action-wriaki-p/
Eric.
On Mon, Apr 18, 2011 at 11:05 PM, Sean Cribbs wrote:
> Sorry for being dismissive, I do understand what you'
Sorry for being dismissive, I do understand what you're after. I'm just saying
that if your application needs those semantics, build them in -- don't expect
Riak's vector clocks to do the work for you. Keep a list of the most recent
"change" events either in that object or alongside, or keep a c
I'm not missing the point you think I am. Riak already has the
ability to store more than one value for a key/value pair. I'd like
an option - possibly named something new, that used this to store a
limited amount of history so that clients could be presented with a
common ancestor when that was
I think you're missing a key point here, and that is that the vector clock
doesn't store copies of the *values*, only the individual "touches" of
identified clients. I'm not sure what computing the common ancestor is going to
give you if you don't have the value. Vector clocks are essentially o
Riak's small_vclock, big_vclock, young_vclock, and old_vclock
parameters already give control over pruning behavior. If there isn't
enough history to compute a common ancestor, then return nothing for
the common ancestor.
The use case here really isn't an SCM. The use case is when two
clients ge
Yes, but vector clocks are for resolution of race-conditions and network
partitions, not to provide an SCM history. Imagine how much space would be
consumed by the history long enough to disambiguate an object that has been
updated normally 1000 times, followed by one bad client that decides wr
I actually had a question about that page. Why is it that when there
is a conflict we can only get the conflicting versions of the data?
If I'm going to try to resolve the conflict intelligently, I really
want the common ancestor as well so that I can try to do a 3-way
merge.
Good call. If an a
On Mon, Apr 18, 2011 at 4:59 PM, Dan Reverri wrote:
> Hi Bryan,
> This is an excellent question and one of the more difficult areas of Riak to
> understand. The source of confusion in this situation is vector clocks. Riak
> maintains a vector clock for every object which is used to track different
On Mon, Apr 18, 2011 at 4:59 PM, Dan Reverri wrote:
>
> I've tried to provide a walk through below that explains the behavior. The
> main lesson to take away is you should always provide a client id and vector
> clock.
>
Thanks for the description of what's going on. From your description, it
lo
Hi Bryan,
This is an excellent question and one of the more difficult areas of Riak to
understand. The source of confusion in this situation is vector clocks. Riak
maintains a vector clock for every object which is used to track different
versions of the object and potentially auto-repair out-of-s
I have an app using the protobuf API that's exhibiting some strange
behaviour.
I have a bucket with allow_mult = true, so when I perform a PUT I expect
that if a matching key exists, a sibling will be created, and the response
to the PUT should contain both the pre-existing value and the new value
15 matches
Mail list logo
