query processor: treat view changes at least as table changes
When a base table changes and altered, so does the views that might refer to the added column (which includes "SELECT *" views and also views that might need to use this column for rows lifetime (virtual columns). However the query processor implementation for views change notification was an empty function. Since views are tables, the query processor needs to at least treat them as such (and maybe in the future, do also some MV specific stuff). This commit adds a call to `on_update_column_family` from within `on_update_view`. The side effect true to this date is that prepared statements for views which changed due to a base table change will be invalidated. Fixes #16392 Signed-off-by: Eliran Sinvani <eliransin@scylladb.com>
This commit is contained in:
@@ -1084,6 +1084,9 @@ void query_processor::migration_subscriber::on_update_aggregate(const sstring& k
|
||||
void query_processor::migration_subscriber::on_update_view(
|
||||
const sstring& ks_name,
|
||||
const sstring& view_name, bool columns_changed) {
|
||||
// scylladb/scylladb#16392 - Materialized views are also tables so we need at least handle
|
||||
// them as such when changed.
|
||||
on_update_column_family(ks_name, view_name, columns_changed);
|
||||
}
|
||||
|
||||
void query_processor::migration_subscriber::on_update_tablet_metadata() {
|
||||
|
||||
Reference in New Issue
Block a user