Review schema updates
Cassis turns a schema update into a plan: the schema diff, and every context change it implies. Nothing is written until you apply, and applying does exactly what the plan lists.
Open the Schema page. Two actions produce a plan: Sync from warehouse on a connected project, and Update from DDL on a project whose schema comes from an uploaded file. Cassis computes the plan and opens it for review.
Read the plan
- Schema diff
- Stored schema against the new one, one row per table or column added, changed, or removed. Source metadata changes show their before and after values.
- Context changes
- What Cassis will do about it, applied exactly as listed: renames carried over to the tables and columns the context describes, dropped columns removed with the joins and metrics that reference them, tables that leave the context. Tables outside the context only move the schema.
- Warnings
- What the update costs: a placed table about to lose its description, a metric whose expression refers to a column that is going away. Read these before applying.
Apply writes the schema version and the context changes together, in one step. Discard drops the plan and leaves everything as it was. A plan you leave open is marked out of date once the context or the stored schema moves on, so you plan again rather than apply a stale one.
Modeling stays a separate step. A table that appears in the source is tracked by the plan but not placed in the context; place and describe it afterwards, in the app or in the repository, the way you model any table.
Plans Cassis makes for you
Every night Cassis plans a warehouse sync for each connected project. When the source moved, the Schema page shows A plan is waiting with the number of context changes until someone reviews it. When the source did not move, no plan is left behind. A plan you start yourself replaces the waiting one.
What a DDL upload covers
A DDL file speaks only for the schemas it contains. A partial export, such as Snowflake’s per-schema GET_DDL, adds or updates those schemas and leaves the rest of the source alone. The upload dialog asks which one you have: Update only the schemas in the file, or Replace the complete source schema, where a schema missing from the file counts as dropped. From a pipeline, cassis schema push makes the same choice with --complete.
USE SCHEMA and USE DATABASE statements are honored, so an export whose CREATE TABLE statements carry no schema name still lands in the right schema. Table and column names match case-insensitively, so re-exporting the same schema in another case plans no changes instead of phantom renames and removals.
Cassis refuses a file it cannot trust rather than plan half a schema. Diagnostics identify failed objects and list what Cassis did extract. An incomplete plan cannot be applied. A truncated or corrupted export fails with a prompt to re-export. A file that removes most tracked tables in a covered schema fails with the question “is the file complete?”, instead of planning all those removals.
From a checkout or CI
The same plan runs headlessly: cassis schema plan previews it, cassis schema apply writes the resulting context files into a git checkout for git diff, and cassis schema push applies it to the app. On a connected project, --warehouse plans from the live source, so a migration pipeline can update the context the moment it merges.
Follow the project’s editing path. Apply in the app for an app-managed project. For a git-managed project, run cassis schema apply and commit, or cassis schema push from the pipeline, so the next import does not overwrite the app edit.