Getting the same TimeUUID values might be a major problem. Getting two different TimeUUIDs that at least have time component would not be a major problem as this is the main case today. Getting different time components is actually the corner case, and it is a corner case that breaks Internet-of-Things applications. We can tightly control clock skew in our cluster. We most definitely CANNOT control clock skew on the thousands of sensors that write to our cluster.
Thanks, Cody On Wed, Nov 30, 2016 at 5:33 PM, Robert Wille <rwi...@fold3.com> wrote: > 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> 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> 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> >> 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 >> > >
