On Tue, Apr 6, 2010 at 9:11 AM, Paul Prescod <pres...@gmail.com> wrote: > This may be the blind leading the blind... > On Mon, Apr 5, 2010 at 11:54 PM, Tatu Saloranta <tsalora...@gmail.com> > wrote: >>... > >> >> I think the key is that this is not automatic -- there is no general >> mechanism for aggregating distinct modifications. Point being that you >> could choose one amongst right answers, but not what to do with >> concurrent modifications. So what is done instead is have >> application-specific resolution strategy which makes use of semantics >> of operations, to know how to combine such concurrent modifications >> into "correct" answer. > > I agree with all of that. > >> >> I don't know if this is trivial for case of >> counter increments: especially since two concurrent increments give >> same new value; yet correct combined result would be one higher (both >> used base, added one). > > As long as the conflict resolver knows that two writers each tried to > increment, then it can increment twice. The conflict resolver must know > about the semantics of "increment" or "decrement" or "string append" or > "binary patch" or whatever other merge strategy you choose. You'll register > your "strategy" with Cassandra and it will apply it. Presumably it will also > maintain enough context about what you were trying to accomplish to allow > the merge strategy plugin to do it properly.
as long as operations are commutative, isn't the conflict resolution simply "apply all" ? A large number of useful operations can be implemented this way (numeric incr/decr, set ops etc)
