cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ariel Weisberg <>
Subject Re: Why does `now()` produce different times within the same query?
Date Tue, 29 Nov 2016 22:41:48 GMT

The function is defined here[1]. I hope my email client isn't
butchering the code.

public static final Function *nowFct *= new NativeScalarFunction("now",

    public ByteBuffer execute(ProtocolVersion protocolVersion,
    List<ByteBuffer> parameters)

        return ByteBuffer.*wrap*(UUIDGen.*getTimeUUIDBytes*());


It's documented as
> The now function takes no arguments and generates, on the coordinator
> node, a new unique timeuuid (at the time where the statement using it
> is executed).
> Now is the behavior consistent with the documentation? Well it depends
> on how you define statement (CQL statement, or function call) I
> suppose. I do think the doc needs to be updated because in terms of
> principle of least surprise yes this is a little surprising.

I know of a couple of systems that associate a timestamp with each
transaction and will always return the same time when you request the
current time. However you aren't requesting the current time you are
requesting a UUID using a function named now().  I think we are stuck
with the behavior and need an additional function that does what would
expect from a function named now().

As a work around you can pass the time in as a parameter and then you
can guarantee it will be the same in each position.

There is also the implicit for
each column. Writetime didn't seem have hits in the Apache docs so I
linked to the Datastax docs. I'll see about getting them updated.



On Tue, Nov 29, 2016, at 04:49 PM, Terry Liu wrote:

> It appears that a single query that calls Cassandra's `now()`
> time function may actually cause a query to write or return
> different times.

> Is this the expected or defined behavior, and if so, why does it
> behave like this rather than evaluating `now()` once across an entire
> statement?

> This really affects UPDATE statements but to test it more easily, you
> could try something like:

> SELECT toTimestamp(now()) as a, toTimestamp(now()) as b

> FROM keyspace.table

> LIMIT 100;


> If you run that a few times, you should eventually see that the
> timestamp returned moves onto the next millisecond mid-query.

> -- 

> *Software Engineer*

> Turnitin -[2]




View raw message