Your last sentence is correct - TWCS and dtcs add meaning (date/timestamp) to
the long writetime that the rest of Cassandra ignores. If you're trying to
backload data, you'll need to calculate the TTL yourself per write like you
calculate the writetime.
The TTL behavior doesn't consider the cli
Indeed, the TTL is computed based on LOCAL timestamp of the server and not
based on the PROVIDED timestamp by the client ... (according to Mastering
Apache Cassandra, 2nd edition, Nishant Neeraj, PackPublishing)
On Wed, Dec 28, 2016 at 10:15 PM, Voytek Jarnot
wrote:
> >It's not clear to me why f
>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.
Simple use-case: want to load historical data, want to use TWCS, want to
use TTL.
Scenario:
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
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
