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.
Cheers Robert On Nov 30, 2016, at 4:46 PM, Todd Fast <t...@digitalexistence.com<mailto:t...@digitalexistence.com>> wrote: 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. Todd On Wed, Nov 30, 2016 at 12:37 PM Terry Liu <t...@turnitin.com<mailto:t...@turnitin.com>> wrote: 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<mailto: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<mailto: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<http://www.turnitin.com/> t...@turnitin.com<mailto:t...@turnitin.com> -- Software Engineer Turnitin - http://www.turnitin.com<http://www.turnitin.com/> t...@turnitin.com<mailto:t...@turnitin.com>
