[
https://issues.apache.org/jira/browse/CASSANDRA-10690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011267#comment-15011267
]
Jeremiah Jordan commented on CASSANDRA-10690:
---------------------------------------------
bq. 'll give my very personal opinion for what it's worth: the 2ndary API has
been entirely rewritten for 3.0 with a fair emphasis on custom indexes and, to
the best of my knowledge, no realistic implementation using it has yet been
finished. So I think it's silly to call that API anything else that a beta and
we'll be lucky if this is the only "problem" found by people actually trying to
use it in real life.
Agreed. I think we should get this interface right now, and not leave
something ambiguous in 3.0.
bq. But later (starting with 3.3? 3.5?) - once we stabilise, we should
absolutely not break the rule.
Also agreed. If we want to do this we need to do it now.
> Remove unclear indexes() method from 2ndary index API
> -----------------------------------------------------
>
> Key: CASSANDRA-10690
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10690
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Reporter: Tyler Hobbs
> Fix For: 3.2
>
>
> The new secondary index API does not notify indexes of single-row or slice
> deletions unless specific columns are deleted. I believe the problem is that
> in {{SecondaryIndexManager.newUpdateTransaction()}}, we skip indexes unless
> {{index.indexes(update.columns())}}. When no columns are specified in the
> the deletion, {{update.columns()}} is empty, which causes all indexes to be
> skipped.
> I think the correct fix is to do something like this in the
> {{ModificationStatement}} constructor:
> {code}
> if (type == StatementType.DELETE && modifiedColumns.isEmpty())
> modifiedColumns = cfm.partitionColumns();
> {code}
> However, I'm not sure if that may have unintended side-effects. What do you
> think, [~slebresne]?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
