[ https://issues.apache.org/jira/browse/CASSANDRA-18352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jordan West updated CASSANDRA-18352: ------------------------------------ Test and Documentation Plan: Added 2 new tests Status: Patch Available (was: Open) PR: [https://github.com/apache/cassandra/pull/2246] Test: [j8|https://app.circleci.com/pipelines/github/jrwest/cassandra/156/workflows/aa68c379-040a-4a6e-ad8f-5f71aaeecf34] [j11|https://app.circleci.com/pipelines/github/jrwest/cassandra/156/workflows/06e61722-30c7-4ef9-b31b-ce2a11550ac0] (I checked the test failures also match trunk but can re-run if they get fixed) > Add Option to Timebox write timestamps > -------------------------------------- > > Key: CASSANDRA-18352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18352 > Project: Cassandra > Issue Type: New Feature > Components: CQL/Semantics > Reporter: Jordan West > Assignee: Jordan West > Priority: Normal > > In several cases it is desirable to have client provided timestamps generated > at the application-level. This can be error prone, however. In particular, > applications can choose timestamps that may be nonsensical for a given > application. One dangerous manifestation of this is the "doomstone" (a > tombstone far in the future of any realistic write). This feature would allow > either operators or users to specify a minimum and maximum timebound of > "reasonable" timestamps. The default would be negative infinity, positive > infinity to maintain backwards compatibility. Writes that are USING TIMESTAMP > with a timestamp outside of the timebox will see an exception. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org