The purpose of timestamps is to guarantee out-of-order conflicting writes are resolved as last-write-wins. Cassandra doesn't really expect you to be writing timestamps with wide variations from record to record. Indeed, if you're doing this, it'll violate some of the assumptions in places such as time windowed / date tiered compaction. It's possible to dodge those landmines but it would be hard to know if you got it wrong.
I think in general timestamp manipulation is *caveat utilitor*. It's not clear to me why for your use case you would want to manipulate the timestamps as you're loading the records unless you're concerned about conflicting writes getting applied in the correct order. Probably worth a footnote in the documentation indicating that if you're doing both USING TTL and WITH TIMESTAMP that those don't relate to each other. At rest TTL'd records get written with an expiration timestamp, not a delta from the writetime. On Wed, Dec 28, 2016 at 9:38 AM Voytek Jarnot <voytek.jar...@gmail.com> wrote: > It appears as though, when inserting with "using ttl [foo] and timestamp > [bar]" that the TTL does not take the provided timestamp into account. > > In other words, the TTL starts at insert time, not at the time specified > by the timestamp. > > Similarly, if inserting with just "using timestamp [bar]" and relying on > the table's default_time_to_live property, the timestamp is again ignored > in terms of TTL expiration. > > Seems like a bug to me, but I'm guessing this is intended behavior? > > Use-case is importing data (some of it historical) and setting the > timestamp manually (based on a timestamp within the data itself). Anyone > familiar with any work-arounds that don't rely on calculating a TTL > client-side for each record? >
