[
https://issues.apache.org/jira/browse/CASSANDRA-19130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18005209#comment-18005209
]
Stefan Miklosovic edited comment on CASSANDRA-19130 at 7/14/25 5:45 PM:
------------------------------------------------------------------------
I dont know ... feels strange. Are not there some consequences when driver is
connected to a cluster? No clue ... Is not that caching tables somehow or what?
I think it has a listener which listens on dropped and created tables so if we
implemented like you suggest, if we dont do it differently then this would come
to the driver right?
Also I am not completely sure about the semantics here. With current approach,
the underlying table still exists. With this new approach, if it is not done
atomically, then could not this happen?
1) we drop a table
2) a mutation comes
3) we create a table
So 2) would fail because it just came after we dropped but before we created it.
I think the atomicity of this is pretty much a must, right?
was (Author: smiklosovic):
I dont know ... feels strange. Are not there some consequences when driver is
connected to a cluster? No clue ... Is not that caching tables somehow or what?
I think it has a listener which listens on dropped and created tables so if we
implemented like you suggest, if we dont do it differently then this would come
to the driver right?
Also I am not completely sure about the semantics here. With current approach,
the underlying table still exists. With this new approach, if it is not done
atomically, then could not this happen?
1) we drop a table
2) a mutation comes
3) we create a table
So 2) would fail because it just came after we dropped but before we created it.
I think the atomicy of this is pretty much a must, right?
> 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]
