[ 
https://issues.apache.org/jira/browse/CASSANDRA-10438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947467#comment-14947467
 ] 

Ariel Weisberg commented on CASSANDRA-10438:
--------------------------------------------

OK, so the downstream stuff isn't particularly sensitive to what the liveness 
info already was set to in past releases? I am just trying to understand how 
this is going to impact the contract between the manager and the downstream 
index implementations. I suppose the prior answer was wrong and we will have to 
fix anything that comes up downstream. I don't know how many implementations 
there are out in the wild that might be impacted.

When I looked at it it seemed like the only thing it is used for is to get the 
TTL for primary key indexes, and in that case it was for the new row only. That 
was of course the one case where it was already setting it modulo the bug. 

3.0-testall timed out during the build so I ran it again.

Otherwise +1.



> Overwrites of rows in memtable produce incorrect deltas for indexing
> --------------------------------------------------------------------
>
>                 Key: CASSANDRA-10438
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10438
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sam Tunnicliffe
>            Assignee: Sam Tunnicliffe
>             Fix For: 3.0.0 rc2
>
>
> When a row in the memtable is updated, the delta is supplied to any 
> registered indexer. This consists of two {{Row}} objects, representing the 
> old and new data in the memtable. As per its javadoc, the contract of 
> {{Index.Indexer::updateRow}} is that these old & new rows contain only the 
> changed columns, so any column which was not affected by the update will 
> appear in neither the new nor old row. The {{RowDiffListener::onCell}} method 
> in {{SecondaryIndexManager.WriteTimeTransaction::onUpdated}} which produces 
> these deltas uses a reference equality check, where it should be checking 
> object equality. This results in unchanged, prexisting cells appearing in the 
> {{toInsert}} row.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to