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 <voytek.jar...@gmail.com> wrote: > >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: > Importing data using standard write path (inserts) > Using timestamp to give TWCS something to work with (import records > contain a created-on timestamp from which I populate "using timestamp") > Need records to expire according to TTL > Don't want to calculate TTL for every insert individually (obviously what > I want and what I get differ) > I'm importing in chrono order, so TWCS should be able to keep things from > getting out of hand. > > >I think in general timestamp manipulation is *caveat utilitor*. > > Yeah; although I'd probably choose stronger words. TWCS (and perhaps > DTCS?) appears to treat writetimes as timestamps; the rest of Cassandra > appears to treat them as integers. > > > On Wed, Dec 28, 2016 at 2:50 PM, Eric Stevens <migh...@gmail.com> wrote: > >> 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? >>> >> >
