One millisecond is not an issue in most of Internet of Things projects out there. There are lots of connection related things that add far more latency to the requests than that. Especially if you take into account the time it takes for the data to actually come to a cassandra node in the background etc. I'm simply not aware of any larger projects where edge devices write directly to cassandra.
Requests almost always come in to some sort of gateway before that. The usual pattern is storing the timestamp measured on the device (if it even has own clock) and timestamp when it was received on the platform side. Having two same timestamps on millisecond level in one insert statement generated by now() simply doesn't add that much to the table. Only case that comes to my mind would be when there is time series bucketing of inserts and placing measurements in partitions based on some sort of a mapping function with the results of now() but then again this is usually done on the server side, I'm not sure it would be best practice to do it within the insert. Even if it would be done that way, analytics (be it near real time or batch) usually takes that kind of things into account and compensates - reports rarely show millisecond level dynamics. In the end it just wouldn't be a good idea to change behaviour of a function being around for quite some time. @msvaljek <https://twitter.com/msvaljek> 2016-12-01 18:10 GMT+01:00 Cody Yancey <yan...@uber.com>: > On Thu, Dec 1, 2016 at 11:09 AM Sylvain Lebresne <sylv...@datastax.com> > wrote: > >> there is much much more trivial solution: generate it client side. The >> `now()` function is a small convenience but there is nothing you cannot do >> without it client side >> > > Please see my post above as to why this is a bad idea for inserts based on > request time where knowing the time the request was made is actually > important. > > Cody > >> >
