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 this. Thanks for the quick responses! -Terry On Tue, Nov 29, 2016 at 2:45 PM, Marko Švaljek <msval...@gmail.com> wrote: > 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. > > > @msvaljek <https://twitter.com/msvaljek> > > 2016-11-29 22:49 GMT+01:00 Terry Liu <t...@turnitin.com>: > >> 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 - http://www.turnitin.com >> t...@turnitin.com >> > > -- *Software Engineer* Turnitin - http://www.turnitin.com t...@turnitin.com
