There's more burden on the user, but with a benefit– client supplied
timestamps mean that client retries are idempotent as long as they use
the same timestamp.*
-ryan
* doesn't apply to counters
On Fri, Jun 17, 2011 at 8:01 AM, Tim Wisniewski wrote:
> it's slightly less burden on the user
>
> O
The timestamp of a column is an arbitrary version number, the value of which
is determined by the client that created the column. It's merely convention
(and convenience) that clients use the current timestamp. Since the
timestamp is a client-concern, and in non-trivial topologies Cassandra may
not
It makes the overall system more bullet proof
On Fri, Jun 17, 2011 at 11:01 AM, Tim Wisniewski wrote:
> it's slightly less burden on the user
>
>
> On Fri, Jun 17, 2011 at 11:00 AM, Gary Dusbabek wrote:
>
>> That problem is already solved externally. I don't see the value of
>> reimplementing i
it's slightly less burden on the user
On Fri, Jun 17, 2011 at 11:00 AM, Gary Dusbabek wrote:
> That problem is already solved externally. I don't see the value of
> reimplementing it inside of cassandra.
>
> Gary.
>
> On Fri, Jun 17, 2011 at 09:58, Tim Wisniewski wrote:
> > Hi,
> >
> > My unde
That problem is already solved externally. I don't see the value of
reimplementing it inside of cassandra.
Gary.
On Fri, Jun 17, 2011 at 09:58, Tim Wisniewski wrote:
> Hi,
>
> My understanding is data corruption can occur if the node clocks are too far
> out of sync. Â What if Cassandra nodes ma
Hi,
My understanding is data corruption can occur if the node clocks are too far
out of sync. What if Cassandra nodes maintained an internal time sync via
ntp or something?
-Tim
