cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Wille <>
Subject Re: Why does `now()` produce different times within the same query?
Date Thu, 01 Dec 2016 00:33:46 GMT
In my opinion, this is not broken and “fixing” it would break existing code. Consider a
batch that includes multiple inserts, each of which inserts the value returned by now(). Getting
the same UUID for each insert would be a major problem.



On Nov 30, 2016, at 4:46 PM, Todd Fast <<>>

FWIW I'd suggest opening a bug--this behavior is certainly quite unexpected and more than
just a documentation issue. In general I can't imagine any desirable properties of the current
implementation, and there are likely a bunch of latent bugs sitting out there, so it should
be fixed.


On Wed, Nov 30, 2016 at 12:37 PM Terry Liu <<>>
Sorry for my typo. Obviously, I meant:
"It appears that a single query that calls Cassandra's`now()` time function multiple times
may actually cause a query to write or return different times."

Less of a surprise now that I realize more about the implementation, but I agree that more
explicit documentation around when exactly the "execution" of each now() statement happens
and what implications it has for the resulting timestamps would be helpful when running into

Thanks for the quick responses!


On Tue, Nov 29, 2016 at 2:45 PM, Marko Švaljek <<>>
every now() call in statement is under the hood "replaced" with newly generated uuid.

It can happen that they belong to  different milliseconds in time.

If you need to have same timestamps you need to set them on the client side.


2016-11-29 22:49 GMT+01:00 Terry Liu <<>>:
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

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 -<><>

Software Engineer
Turnitin -<><>

View raw message