Is that the actual reason? This seems like a big inefficiency to me. For those of us who don't worry about this extreme edge case (that probably will NEVER happen in real life, for most applications), is there a way to turn this off?
Or am I wrong about this making the operation MUCH more expensive? On Wed, Jul 13, 2011 at 3:20 PM, Boris Yen <yulin...@gmail.com> wrote: > For a specific column, If there are two versions with the same timestamp, > the value of the column is used to break the tie. > > if v1.value().compareTo(v2.value()) < 0, it means that v2 wins. > > On Wed, Jul 13, 2011 at 7:13 PM, David Boxenhorn <da...@citypath.com>wrote: > >> How would you know which data is correct, if they both have the same >> timestamp? >> >> On Wed, Jul 13, 2011 at 12:40 PM, Boris Yen <yulin...@gmail.com> wrote: >> >>> I can only say, "data" does matter, that is why the developers use hash >>> instead of timestamp. If hash value comes from other node is not a match, a >>> read repair would perform. so that correct data can be returned. >>> >>> >>> On Wed, Jul 13, 2011 at 5:08 PM, David Boxenhorn <da...@citypath.com>wrote: >>> >>>> If you have to pieces of data that are different but have the same >>>> timestamp, how can you resolve consistency? >>>> >>>> This is a pathological situation to begin with, why should you waste >>>> effort to (not) solve it? >>>> >>>> On Wed, Jul 13, 2011 at 12:05 PM, Boris Yen <yulin...@gmail.com> wrote: >>>> >>>>> I guess it is because the timestamp does not guarantee data >>>>> consistency, but hash does. >>>>> >>>>> Boris >>>>> >>>>> >>>>> On Wed, Jul 13, 2011 at 4:27 PM, David Boxenhorn >>>>> <da...@citypath.com>wrote: >>>>> >>>>>> I just saw this >>>>>> >>>>>> http://wiki.apache.org/cassandra/DigestQueries >>>>>> >>>>>> and I was wondering why it returns a hash of the data. Wouldn't it be >>>>>> better and easier to return the timestamp? You don't really care what the >>>>>> data is, you only care whether it is more or less recent than another >>>>>> piece >>>>>> of data. >>>>>> >>>>> >>>>> >>>> >>> >> >