[ 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