[
https://issues.apache.org/jira/browse/CASSANDRA-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297189#comment-16297189
]
Jon Haddad commented on CASSANDRA-8527:
---------------------------------------
{quote}
The way the code is architected, I don't see a way of returning the number of
range tombstones without pretty deep changes.
Counting the number of deleted rows is already very interesting and would not
require dangerous modifications.
{quote}
OK, we can do it as a follow up.
{quote}
But if we can't do this in a new major version, then when is the appropriate
time ?
A first step could be to introduce a flag and an additional warning.
It would be something like :
{quote}
I'm not saying we shouldn't do it in this version. I think we should kick this
discussion into the dev ML to get some more eyes on it. As far as I can tell,
the options are
1. Keep the old behavior
2. Keep new
3. Config for picking
4. Separate config options for both.
{quote}
Do you think adding Mockito to the list of dependencies is reasonable/wanted ?
{quote}
I have no objections, and I think it would help make the codebase more
testable.
> Account for range tombstones wherever we account for tombstones
> ---------------------------------------------------------------
>
> Key: CASSANDRA-8527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8527
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Alexander Dejanovski
> Fix For: 4.x
>
> Attachments: CASSANDRA-8527.diff
>
>
> As discussed in CASSANDRA-8477, we should make sure the tombstone thresholds
> also apply to range tombstones, since they poses the same problems than cell
> tombstones.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
