fix(redshift): do not recreate existing views on every evaluation

[gandeevanraghuramandd]

Description

Problem

VIEW models have intervals like any other model kind (default cron @daily), so every plan or run that fills a missing interval for a view calls ViewStrategy.insert. For engines without view binding (HAS_VIEW_BINDING = False), must_recreate_view is always True for regular views, so an existing view is recreated on every interval evaluation even when its definition has not changed.

On Redshift this is particularly disruptive:

• RedshiftEngineAdapter inherits BasePostgresEngineAdapter.create_view, which with replace=True issues DROP VIEW IF EXISTS ... CASCADE followed by CREATE VIEW ... WITH NO SCHEMA BINDING.
• The DROP + CREATE gives the view a new OID. Queries that are concurrently reading through that view (directly, or through other late-binding views) fail with could not open relation with OID <n>.
• The DROP takes an exclusive lock and can queue behind long-running readers.
• Environments that share a snapshot version share the same physical view. A plan in one environment that fills a routine daily interval for a shared view (e.g. sqlmesh__analytics.analytics__example_view__<version>) recreates it underneath queries running in another environment, which makes these failures more likely.

Change

• Add an engine adapter class attribute RECREATE_VIEW_ON_EVALUATION (default True, so current behavior is preserved), next to the existing RECREATE_MATERIALIZED_VIEW_ON_EVALUATION.
• Set RECREATE_VIEW_ON_EVALUATION = False on RedshiftEngineAdapter.
• In ViewStrategy.insert, when the adapter opts out, an existing regular (non-materialized) view is only recreated when is_first_insert is True. Otherwise it takes the existing "Skipping creation of the view" path. This mirrors how RECREATE_MATERIALIZED_VIEW_ON_EVALUATION already gates materialized views.

is_first_insert is the right signal because it is already computed as (not intervals or not target_table_exists) and batch_index == 0, so it covers both cases where a view really needs recreating:

1. The physical view is missing (or this is a new version).
2. should_force_rebuild (new.is_view and new.is_indirect_non_breaking and not new.is_forward_only) cleared the view's intervals so it gets repointed after an upstream change.

Routine interval fills of an existing view have is_first_insert=False and no longer issue DDL on Redshift.

Unchanged:

• All other engines, including other non-binding engines (Snowflake, BigQuery, Databricks, ...), which may rely on recreation to pick up upstream column changes.
• Materialized view handling on all engines, including Redshift.
• ViewStrategy.create, which already never replaces an existing view.

Test Plan

Added test_evaluate_existing_view_recreation in tests/core/test_snapshot_evaluator.py. It runs SnapshotEvaluator.evaluate against real RedshiftEngineAdapter / SnowflakeEngineAdapter instances with mocked connections and an existing physical view, then checks the view DDL that gets issued:

Engine	Kind	Intervals (is_first_insert)	Expected
Redshift	VIEW	present (False)	no DROP/CREATE VIEW
Redshift	VIEW	none (True)	DROP VIEW + CREATE VIEW
Redshift	VIEW (materialized)	present	recreated (unchanged)
Snowflake	VIEW	present	CREATE OR REPLACE VIEW (unchanged)
Snowflake	VIEW	none	CREATE OR REPLACE VIEW (unchanged)
Snowflake	VIEW (materialized)	present	CREATE OR REPLACE MATERIALIZED VIEW (unchanged)

With the source change reverted, only the Redshift routine-evaluation case fails, as expected.

Commands run locally (Python 3.12):

• pytest tests/core/test_snapshot_evaluator.py -k test_evaluate_existing_view_recreation: 6 passed
• pytest -n 8 tests/core/test_snapshot_evaluator.py tests/core/engine_adapter/test_redshift.py tests/core/engine_adapter/test_starrocks.py tests/core/integration/test_forward_only.py: 350 passed (one earlier run had a single failure in test_forward_only.py::test_full_history_restatement_model_regular_plan_preview_enabled that did not reproduce in isolation, serially, or in 3 further parallel runs)
• pytest -n auto -m "fast and not cicdonly and not isolated" tests/core: 2082 passed, 3 skipped
• make style: ruff, ruff-format, mypy, valid migrations all passed

Not tested against a live Redshift cluster.

Open questions for maintainers

1. Upstream column changes on Redshift. This change assumes an existing Redshift late-binding view does not need to be recreated to stay correct unless is_first_insert is set. I have not verified this against a live cluster. The case I am least sure about is a forward-only additive upstream change behind SELECT *. should_force_rebuild skips forward-only snapshots, and SQLMesh renders SELECT * into an explicit column list (the generated DDL looks like CREATE VIEW ... ("a") AS SELECT "a" AS "a" ...), so with this change the existing view would probably not expose the new column until it is recreated for some other reason. Previously the next interval evaluation would have recreated it with the new column list. Is that acceptable for Redshift, or should this case still trigger a recreation (for example by comparing the rendered column list with the existing view's columns)?
2. Scope. Would you prefer this as a user-facing opt-in setting (for example on the Redshift connection config or the VIEW kind) rather than an adapter default? Or should it be applied to other non-binding engines too?
3. Redshift materialized true VIEW models. RedshiftEngineAdapter has SUPPORTS_MATERIALIZED_VIEWS = False, so a VIEW model with materialized true is created as a regular view on Redshift. It is still recreated on every evaluation through the materialized-view path, which this PR deliberately leaves unchanged. Should it get the same treatment?

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable)
• All existing tests pass (make fast-test): ran the fast-marked tests under tests/core plus the files listed above, not the full make fast-test target
• My commits are signed off (git commit -s) per the DCO

This change and description were drafted by an AI coding agent (Cursor, Claude) on behalf of the author and reviewed before opening.

Made with Cursor