cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10690) Remove unclear indexes() method from 2ndary index API
Date Wed, 18 Nov 2015 15:31:11 GMT


Aleksey Yeschenko commented on CASSANDRA-10690:

Pragmatically, in this one particular case, yes. We've done it multiple times before on my
memory (.1 of 2.0 and/or 2.1, maybe even later in the game) where going by the rules we shouldn't

Which is to say that I'm fine with committing to 3.0.1/3.1 if we are putting this in 3.x at
all (the sooner the change is visible, the better).

But later (starting with 3.3? 3.5?) - once we stabilise, we should absolutely not break the

FWIW, we have *some* freedom now with default interface method in Java 8, so that's something.

> Remove unclear indexes() method from 2ndary index API
> -----------------------------------------------------
>                 Key: CASSANDRA-10690
>                 URL:
>             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}}
> {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

View raw message