If the entire write operation involves additional LWTs to change the MV, it is uncertain whether users can accept the performance loss of such write operations.
If this CEP is finally accepted, I think users should at least be given the choice of whether to use the old method or the new method, because after all, some users pursue performance rather than strict data consistency（we can provide the ability of disabling or enabling the new mv mv synchronization mechanism）. Another question : What is the frequency of inconsistency detection and repair for mv and base table ? Runtian Liu <curly...@gmail.com> 于2025年5月7日周三 06:51写道： > Hi everyone, > > We’d like to propose a new Cassandra Enhancement Proposal: CEP-48: > First-Class Materialized View Support > <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-48%3A+First-Class+Materialized+View+Support> > . > > This CEP focuses on addressing the long-standing consistency issues in the > current Materialized View (MV) implementation by introducing a new > architecture that keeps base tables and MVs reliably in sync. It also adds > a new validation and repair type to Cassandra’s repair process to support > MV repair based on the base table. The goal is to make MV a first-class, > production-ready feature that users can depend on—without relying on > external reconciliation tools or custom workarounds. > > We’d really appreciate your feedback—please keep the discussion on this > mailing list thread. > > Thanks, > Runtian >
