[
https://issues.apache.org/jira/browse/CASSANDRA-13075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15826423#comment-15826423
]
Sergio Bossa commented on CASSANDRA-13075:
------------------------------------------
[~ifesdjeen],
I believe there are a few problems with your patch:
*
[Passing|https://github.com/ifesdjeen/cassandra/commit/803d3c6ea6e6852103204c7d0bb46001be191ab2#diff-3f2c8994c4ff8748c3faf7e70958520dR550]
the partition columns for the metadata definition is subtly different than
passing the columns for the read partition, as the latter could be a subset of
the former (at least according to javadocs and a brief code inspection); I'm
not sure how much it matters in practice, but that could potentially lead to
unwanted index calls.
*
[Processing|https://github.com/ifesdjeen/cassandra/commit/803d3c6ea6e6852103204c7d0bb46001be191ab2#diff-3f2c8994c4ff8748c3faf7e70958520dR567]
the collected range tombstones inside the loop, piggybacking on the fact the
loop itself will do one more iteration after exhaustion, doesn't actually work,
that is, it seems range tombstones are never processed; this can be easily
verified by checking range tombstones
[here|https://github.com/ifesdjeen/cassandra/commit/803d3c6ea6e6852103204c7d0bb46001be191ab2#diff-13cb97758bcb11cce8fc6f4cb1990dd6R754]
(as this test _should_ check for range tombstones, unless I'm missing
something?).
* Even if the last point worked, I believe that would lead to a duplicate
{{begin}} and {{finish}} call for range tombstones.
*
[Unused|https://github.com/ifesdjeen/cassandra/commit/803d3c6ea6e6852103204c7d0bb46001be191ab2#diff-71513a85468b7cbc97f1e820b06a20a8R125]?
> Indexer is not correctly invoked when building indexes over sstables
> --------------------------------------------------------------------
>
> Key: CASSANDRA-13075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13075
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sergio Bossa
> Assignee: Alex Petrov
> Priority: Critical
> Attachments: CustomIndexTest.java
>
>
> Following CASSANDRA-12796, {{SecondaryIndexManager#indexPartition()}} calls
> each {{Indexer}} {{begin}} and {{finish}} methods multiple times per
> partition (depending on the page size), as
> {{PartitionIterators#getOnlyElement()}} returns an empty partition even when
> the iterator is exhausted.
> This leads to bugs for {{Indexer}} implementations doing actual work in those
> methods, but even worse, it provides the {{Indexer}} the same input of an
> empty partition containing only a non-live partition deletion, as the
> {{Indexer#partitionDelete()}} method is *not* actually called.
> My proposed solution:
> 1) Stop the iteration before the empty partition is returned and ingested
> into the {{Indexer}}.
> 2) Actually call the {{Indexer#partitionDelete()}} method inside
> {{SecondaryIndexManager#indexPartition()}} (which requires to use a filtered
> iterator so it actually contains the deletion info).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
