On Fri, Oct 7, 2011 at 7:23 PM, Tim Robinson <t...@blackstag.com> wrote:
> > > I just read the Satebox page you linked as an example and have a hard time > thinking I would want to use this. While automation is always nice, the > overhead is an unnecessary burden. Since Clojure provides > coordinated/transactional data structures, it's already easy *enough* to > resolve conflicts within your natural code flow without having to resort to > the rationalizing of queued values. Also, I can only speak for myself, but > I believe most people would only want this to apply in selective cases such > that a performance hit is not taken for the other 90% of data where last > write winning is just fine. > > Does that make sense to you? I could be completely off considering I only > read the 5 minute 'read-me' blurb. > > Thanks again. > Tim > > Statebox gives your conflict context when you have a split-brain scenario. If resolution of your data relies on it's history/context, rather than just the latest siblings (e.g. removing an item from a set), then you need to store that context somewhere. Statebox stores the context inline with the object and provides some automatic resolution for certain types of data, such as sets. However, Statebox is Erlang only. You are forced to use Erlang to use it or extend it. I think it would be worthwhile to copy it in a Clojure client as _one_ of the ways to handle conflict resolution. I imagine as a protocol [1] so that you can easily say "this thing participates in sliding-window history-based conflict resolution." -Ryan [1]: My Clojure knowledge is very rusty but IIRC a protocol is much like a type class in Haskell.
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
