[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18005236#comment-18005236
]
Abe Ratnofsky commented on CASSANDRA-19130:
-------------------------------------------
If you do a DROP + CREATE, the driver would get a notification (via REGISTER +
EVENT) of the new table, but we can make it so TRUNCATE doesn't send that
notification.
If a mutation arrives while a TRUNCATE is in-flight, the current behavior
doesn't have clear semantics on whether that mutation is applied, since it
depends on when the flush was executed. I think users are more bothered by
TRUNCATE failing if any node is down, and less bothered by the current lack of
transactional semantics, but we could also remove the mutation rejection window
by having TRUNCATE be its own SchemaTransformation that is executed in a single
epoch.
> Implement transactional table truncation
> ----------------------------------------
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Apache Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
> Reporter: Marcus Eriksson
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TRUNCATE table should leverage cluster metadata to ensure consistent
> truncation timestamps across all replicas. The current implementation depends
> on all nodes being available, but this could be reimplemented as a
> {{Transformation}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
