[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829890#comment-17829890
]
Alex Petrov commented on CASSANDRA-19130:
-----------------------------------------
bq. This will not work in TCM because virtual table is not distributed so there
is basically nothing to commit into TCM and I just return there instantly.
I guess if the intention is to only truncate the table on the local machine,
this might be fine, I just don't think it's user-friendly semantics.
> But when I step aside for a while, is this really what we want to do?
> Truncations committed to TCM? Currently, all nodes need to be up, as already
> described in the description, so here we are moving away from that? I would
> like to have that confirmed.
I think this is what we want to do, yes, since we'll be able to record
truncation timestamp in the log and have it replayed. And the limitation of the
nodes being up will be lifted, too.
> Implement transactional table truncation
> ----------------------------------------
>
> Key: CASSANDRA-19130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19130
> Project: Cassandra
> Issue Type: New Feature
> Components: Consistency/Coordination
> Reporter: Marcus Eriksson
> Assignee: Stefan Miklosovic
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
