[
https://issues.apache.org/jira/browse/CASSANDRA-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-7403:
----------------------------------------
Attachment: 7403-followup.txt
The commit broke
ColumnFamilyStoreTest.testIndexUpdateOverwritingExpiringColumns. It's not
really the fault of the patch, it's more an incompleteness of CASSANDRA-7268,
but since the later has been committed in released versions and the tests broke
with this commit, let's quickly follow up here.
The problem is that the patch CASSANDRA-7268 was not properly rebased on 2.1:
the {{shouldCleanupOldValue}} path was only skipped in the case the new cell is
not live (which is not too useful). Attaching simple followup that fixes that
(I removed the SecondaryIndex.upate method because it was getting in the way, I
figure that was not a big deal but maybe it is for custom indexes?). The patch
also include minor updates of the comments of the patch for this ticket.
> Reconciliation doesn't consider fields specific to expiring cells
> ------------------------------------------------------------------
>
> Key: CASSANDRA-7403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7403
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Sam Tunnicliffe
> Assignee: Benedict
> Fix For: 2.1 rc3
>
> Attachments: 7403-followup.txt
>
>
> Reconciling 2 ExpiringColumns which are equal in every way except for the
> localExpirationTime field will always favour the instance on which reconcile
> is called as fields specific to expiration are not considered.
> This is actually beneficial in pre-2.1 versions as in
> AtomicSortedColumns.Holder.addColumn we call reconcile on the new column,
> which 'wins' the reconcilliation and so the localExpirationTime is
> effectively extended.
> From 2.1 onwards, reconcile is actually called on the existing value (in
> BTreeSortedColumns.ColumnUpdater) and so it wins the reconcilliation and the
> ttl doesn't get extended. The same thing happens in the iterator returned
> from MergeIterator.Reducer.getReducer() so we see the same behaviour when
> merging cells from the multiple SSTables and/or memtables.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
