[CASSANDRA-10362] Potential bugs in MV

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 3.0.0 rc1
• Component/s: Feature/Materialized Views, Legacy/Coordination
• Severity: Normal
• Assignee: Carl Yeksigian
• Reporter: Sylvain Lebresne

Authors

Carl Yeksigian

Reviewers

Sylvain Lebresne

• Created: 17/Sep/15 09:29
• Updated: 16/Apr/19 09:30
• Resolved: 18/Sep/15 10:15

Description

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.