[
https://issues.apache.org/jira/browse/CASSANDRA-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-10362:
---------------------------------------
Component/s: Coordination
> Potential bugs in MV
> --------------------
>
> Key: CASSANDRA-10362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10362
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
> Reporter: Sylvain Lebresne
> Assignee: Carl Yeksigian
> Fix For: 3.0.0 rc1
>
>
> While reviewing CASSANDRA-9664, I notice a few points in {{View.java}} that
> potentially look wrong to me. As those aren't introduced by CASSANDRA-9664,
> I'm opening this ticket separatly. The points in question are:
> * In {{updateAffectsView}}, I don't think the {{row.hasComplexDeletion()}}
> check is correct: if an update only deletes a given collection and that
> collection isn't in the view at all, then I don't think we should care about
> it. Besides, {{hasComplexDeletion}} is not all that efficient and if there is
> a complex deletion, the following loop on the row will catch it (but only if
> the column is interesting). So I think that check should just be removed.
> * Also in {{updateAffectsView}}, I'm surprised we don't check
> {{row.partition.primaryKeyLivenessInfo().isEmpty()}}: if we only insert
> values for the primary key columns, this should still always impact the view.
> * In {{createForDeletionInfo}}, it seems we assume that a live
> {{DeletionInfo}} has either ranges or a partition level deletion, but it can
> have both and it seems we'll only consider the ranges if that's the case,
> which is incorrect.
> It's possible there is a reasoning I'm missing behind how some or all of
> those point are currently work, and if so I apologize, but I think in that
> case said reasoning at least needs to be added as a comment. And if they do
> are problems, it would be nice to add tests for all these cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
