[
https://issues.apache.org/jira/browse/CASSANDRA-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619808#comment-13619808
]
Sam Tunnicliffe commented on CASSANDRA-5397:
--------------------------------------------
I don't really see how we can do that, especially as PRSI is typically
implemented outside of C* and the contract we give it is expressed in the
method signature {{public abstract void index(ByteBuffer rowKey);}} So the
assumption is that an update to a PRSI will be able to access the entire row at
index time.
Changes to AtomicSortedColumns are applied a column at a time so
MixedIndexUpdater has a guard to ensure that even when a mutation changes
multiple columns in the row, the index is only updated once. Obviously though,
until the last of these column updates occurs, the row is not fully updated. So
I see 2 options, defer the per-row indexing until we've finished updating the
row (as in my first patch), or remove the guard and apply the per-row update as
each column is updated. The second option has the benefit of not changing the
SIM.Updater api, but is potentially very inefficient.
> Updates to PerRowSecondaryIndex don't use most current values
> --------------------------------------------------------------
>
> Key: CASSANDRA-5397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5397
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.2.3
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Minor
> Attachments: 5397.txt
>
>
> The way that updates to secondary indexes are performed using
> SecondaryIndexManager.Updater is flawed for PerRowSecondaryIndexes. Unlike
> PerColumnSecondaryIndexes, which only require the old & new values for a
> single column, the expectation is that a PerRow indexer can be given just a
> key which it will use to retrieve the entire row (or as many columns as it
> requires) and perform its indexing on those columns. As the indexes are
> updated before the memtable atomic swap occurs, a per-row indexer may only
> read the previous values for the row, not the new ones that are being
> written. In the case of an insert, there is no previous value and so nothing
> is added to the index.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
