[
https://issues.apache.org/jira/browse/CASSANDRA-10572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982714#comment-14982714
]
Aleksey Yeschenko commented on CASSANDRA-10572:
-----------------------------------------------
Looks pretty straightforward/mechanical.
1. {{canRemoveRow}} does not need this check anymore:
{code}
if (column.type.isCollection())
return false;
{code}
2. I'm very much not a fan of the names of the two methods (before and now). We
still pretty much query the sstables in timestamp order in both cases - if only
for the partition tombstone optimisation. We can just short-circuit it for
{{ClusteringIndexNamesFilter}} and {{queryNeitherCountersNorCollections()}} in
certain conditions.
Otherwise +1 so long as tests are passing.
> SinglePartitionNamesCommand::canRemoveRow omits counter cells it shouldn't
> --------------------------------------------------------------------------
>
> Key: CASSANDRA-10572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10572
> Project: Cassandra
> Issue Type: Bug
> Reporter: Aleksey Yeschenko
> Assignee: Sylvain Lebresne
> Fix For: 3.0.0
>
>
> Like with collections, we can never be sure we've exhausted all the sstables
> when reducing the filter. The sstables can contain legacy local shards that
> need to be summed up. Unless we look into the content of the cells (?), or
> until we get rid of the pre-2.1 values, we must include all the sstables in
> the read (so long as clusterings overlap).
> This was not an issue with 2.1/2.2 as we've forced {{collectAllData}} always
> on that path, but now we don't, and {{SinglePartitionNamesCommand}} should
> handle the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
