@metaobjectsdev/migrate-ts 0.15.21 → 0.16.0-rc.1

package/src/diff/index.ts

@@ -1,6 +1,7 @@
 import type {
   SchemaSnapshot, TableDescriptor, ColumnDescriptor, IndexDescriptor, FkDescriptor,
   ViewDescriptor,
+  DependentRelation,
   Change, ChangeStatus, DiffResult, AllowOptions, AmbiguousCallback, Dialect,
 } from "../types.js";
 import type { SqlType } from "../sql-type.js";
@@ -8,6 +9,7 @@ import { sqlTypeEquals } from "../sql-type.js";
 import { applyStatus } from "./status.js";
 import { detectColumnRenames, detectTableRenames } from "./rename-heuristic.js";
 import { viewSqlEquals } from "../view-sql-compare.js";
+import { viewReplaceIsLegal } from "../view-column-types.js";
 import { checkExprEquals, normalizeCheckExpr } from "../check-expr-compare.js";
 import { DEFAULT_DB_SCHEMA_POSTGRES } from "@metaobjectsdev/metadata";
 
@@ -204,21 +206,26 @@ export async function diff(
     if (args.dialect !== undefined) diffTableChecks(expectedTable, actualTable, changes);
   }
 
-  // Pass 2b: views. Identity is (schema, name). A name present on both sides
-  // with a divergent body (whitespace-/wrapper-normalized) emits replace-view;
-  // introspect now reads the actual body so view-body drift is visible.
+  // Pass 2b: views. Identity is (schema, name). How "changed" is decided is
+  // DIALECT-DEPENDENT — see diffViews.
   const expectedViewsInScope = args.expected.views.filter((v) => inScope(v.schema));
-  diffViews(
-    expectedViewsInScope,
-    args.actual.views.filter((v) => inScope(v.schema)),
-    changes,
-  );
+  const actualViewsInScope = args.actual.views.filter((v) => inScope(v.schema));
+  diffViews(expectedViewsInScope, actualViewsInScope, changes, args.dialect);
 
   // Pass 2c: a column-altering change to a table a view reads forces the view to be
   // dropped before and recreated after — postgres blocks ALTER on a column a view
   // depends on, and sqlite rebuilds the table via recreate-and-copy. Body-unchanged
   // dependent views get no change from Pass 2b, so this is where they're picked up.
-  recreateViewsDependingOnChangedTables(expectedViewsInScope, changes);
+  recreateViewsDependingOnChangedTables(expectedViewsInScope, actualViewsInScope, changes);
+
+  // Any drop-view (from Pass 2b or 2c) that would destroy relations we do NOT manage
+  // must say so — a plain DROP fails at apply, and a CASCADE destroys them for good.
+  //
+  // Deliberately fed the UNSCOPED actual views: CASCADE does not respect our schema
+  // scoping. A downstream application's view lives in ITS OWN schema — precisely the
+  // schema the model never declares, and therefore the one scoping filters out — and
+  // that is exactly the object a cascade must not destroy silently.
+  annotateViewDropDependents(args.actual.views, changes);
 
   // Pass 3: detect table renames BEFORE column renames — so a renamed table's
   // columns are not scanned as orphaned drop/add pairs.
@@ -434,29 +441,147 @@ function viewIdentity(v: { name: string; schema?: string }): string {
   return (v.schema ?? DEFAULT_DB_SCHEMA_POSTGRES) + "." + v.name;
 }
 
+/**
+ * Decide, per view, whether the DB matches the model.
+ *
+ * TWO comparison strategies, because the engines differ in kind, not degree:
+ *
+ *   - SQLite/D1 store the view's SQL verbatim, so comparing the normalized body is
+ *     exact. Unchanged behavior.
+ *
+ *   - Postgres stores a PARSE TREE. `pg_get_viewdef()` deparses it into Postgres's own
+ *     style (`LEFT OUTER JOIN` → `LEFT JOIN`, parenthesized FROM items, lowercased
+ *     functions, dropped aliases), so the text we wrote can NEVER come back. Comparing
+ *     it reported a difference every single time — which is exactly why replace-view
+ *     fired on every migrate, forever, and why `verify --db` was permanently red for
+ *     any project with a projection. Postgres therefore compares FINGERPRINTS: a hash
+ *     of the body we generated, stamped into the view's COMMENT at emit time. Both
+ *     sides of that comparison come from our emitter; the deparser is never consulted.
+ *
+ * An unknown dialect keeps the old body comparison (legacy positional callers hold
+ * hand-built snapshots; changing their semantics silently is worse than leaving them).
+ */
 function diffViews(
   expected: ViewDescriptor[], actual: ViewDescriptor[], changes: Change[],
+  dialect: Dialect | undefined,
 ): void {
   const exp = new Map(expected.map((v) => [viewIdentity(v), v] as const));
   const act = new Map(actual.map((v) => [viewIdentity(v), v] as const));
+
   for (const [id, v] of exp) {
     const a = act.get(id);
     if (a === undefined) {
       changes.push({ kind: "create-view", view: v, ...schemaSpread(v.schema), status: ALLOWED });
-    } else if (
-      // Both bodies known and divergent → replace-view. When either body is
-      // absent (e.g. expected projection unresolvable, or an introspector that
-      // couldn't read the body) we cannot prove a change, so we leave it alone
-      // rather than emit a spurious replace.
-      v.sql !== undefined && a.sql !== undefined && !viewSqlEquals(v.sql, a.sql)
-    ) {
-      changes.push({ kind: "replace-view", view: v, ...schemaSpread(v.schema), status: ALLOWED });
+      continue;
+    }
+
+    if (dialect === "postgres") {
+      // No expected fingerprint (an unresolvable projection body) → we cannot prove a
+      // change. Leave it alone rather than propose a spurious replace.
+      if (v.fingerprint === undefined) continue;
+
+      // The DB view carries no stamp. It is EITHER a view created before fingerprinting
+      // existed, OR somebody's hand-written SQL sitting at a projection's name — and on
+      // Postgres those are indistinguishable, because the deparser destroyed the text
+      // evidence. Overwriting the second destroys work nothing can restore, so fail
+      // closed: propose the replace but BLOCK it pending `allow.adoptView`.
+      if (a.fingerprint === undefined) {
+        changes.push({
+          kind: "replace-view", view: v, ...schemaSpread(v.schema),
+          restore: a, unmanagedActual: true, status: ALLOWED,
+        });
+        continue;
+      }
+
+      // Stamped and equal → converged. THIS is the line that makes `meta migrate` a
+      // no-op on an unchanged schema.
+      if (a.fingerprint === v.fingerprint) continue;
+
+      // Stamped and different → the view genuinely changed. Prefer a non-destructive
+      // CREATE OR REPLACE; fall back to drop+create only when Postgres would refuse it.
+      pushViewUpdate(v, a, changes);
+      continue;
+    }
+
+    // SQLite/D1 (and unknown dialects): verbatim body comparison.
+    if (v.sql !== undefined && a.sql !== undefined && !viewSqlEquals(v.sql, a.sql)) {
+      changes.push({
+        kind: "replace-view", view: v, ...schemaSpread(v.schema), restore: a, status: ALLOWED,
+      });
     }
   }
+
   for (const [id, v] of act) {
     if (!exp.has(id)) {
-      changes.push({ kind: "drop-view", view: v.name, ...schemaSpread(v.schema), status: ALLOWED });
+      changes.push({
+        kind: "drop-view", view: v.name, ...schemaSpread(v.schema), restore: v, status: ALLOWED,
+      });
+    }
+  }
+}
+
+/**
+ * Emit either a non-destructive replace, or the drop+create pair Postgres forces.
+ *
+ * Replace is strictly better when it is legal: dependent views, grants, and the
+ * object's OID all survive. And it IS legal for the common case by construction — a
+ * view's columns come out in projection DECLARATION order, so a field APPENDED to a
+ * projection lands last, which is exactly what Postgres's prefix rule permits.
+ */
+function pushViewUpdate(expected: ViewDescriptor, actual: ViewDescriptor, changes: Change[]): void {
+  const sx = schemaSpread(expected.schema);
+  if (viewReplaceIsLegal(expected.columns, actual.columns)) {
+    changes.push({ kind: "replace-view", view: expected, ...sx, restore: actual, status: ALLOWED });
+    return;
+  }
+  // The column list changed shape (removed / renamed / reordered / retyped), so
+  // Postgres refuses OR REPLACE. The view must be dropped and rebuilt — which is
+  // destructive to anything depending on it (annotateViewDropDependents makes that loud).
+  changes.push({ kind: "drop-view", view: expected.name, ...sx, restore: actual, status: ALLOWED });
+  changes.push({ kind: "create-view", view: expected, ...sx, status: ALLOWED });
+}
+
+/**
+ * Attach, to every planned `drop-view`, the relations a CASCADE would destroy.
+ *
+ * Only EXTERNAL dependents count. A managed view that this same migration drops and
+ * recreates is not a loss — it comes back. Everything else is: an unmanaged view, a
+ * materialized view, or a managed view not part of this migration. Those belong to
+ * someone else, a CASCADE destroys them irrecoverably, and this tool cannot restore
+ * what it does not manage.
+ *
+ * Dependencies are transitive: dropping A cascades to B which cascades to C.
+ */
+function annotateViewDropDependents(actual: readonly ViewDescriptor[], changes: Change[]): void {
+  const byId = new Map(actual.map((v) => [viewIdentity(v), v] as const));
+  // Views this migration drops AND recreates — they survive the migration, so a
+  // dependent that is one of them is not destroyed.
+  const recreated = new Set(
+    changes
+      .filter((c): c is Extract<Change, { kind: "create-view" }> => c.kind === "create-view")
+      .map((c) => viewIdentity(c.view)),
+  );
+
+  for (const c of changes) {
+    if (c.kind !== "drop-view") continue;
+    const dropped = viewIdentity({ name: c.view, ...(c.schema !== undefined ? { schema: c.schema } : {}) });
+
+    // Transitive closure over the dependency edges introspection gave us.
+    const seen = new Set<string>([dropped]);
+    const queue = [dropped];
+    const external: DependentRelation[] = [];
+    while (queue.length > 0) {
+      const cur = queue.shift()!;
+      for (const dep of byId.get(cur)?.dependents ?? []) {
+        const depId = viewIdentity(dep);
+        if (seen.has(depId)) continue;
+        seen.add(depId);
+        queue.push(depId);
+        if (dep.managed && recreated.has(depId)) continue;   // comes back — not a loss
+        external.push(dep);
+      }
     }
+    if (external.length > 0) c.dependents = external;
   }
 }
 
@@ -468,8 +593,10 @@ const VIEW_RECREATE_TRIGGERS = new Set<Change["kind"]>([
 
 function recreateViewsDependingOnChangedTables(
   expectedViews: ViewDescriptor[],
+  actualViews: ViewDescriptor[],
   changes: Change[],
 ): void {
+  const actualById = new Map(actualViews.map((v) => [viewIdentity(v), v] as const));
   const alteredTables = new Set<string>();
   for (const c of changes) {
     if (VIEW_RECREATE_TRIGGERS.has(c.kind)) {
@@ -494,7 +621,12 @@ function recreateViewsDependingOnChangedTables(
       const c = changes[i]!;
       if (c.kind === "replace-view" && viewIdentity(c.view) === id) changes.splice(i, 1);
     }
-    changes.push({ kind: "drop-view", view: v.name, ...schemaSpread(v.schema), status: ALLOWED });
+    const prior = actualById.get(id);
+    changes.push({
+      kind: "drop-view", view: v.name, ...schemaSpread(v.schema),
+      ...(prior !== undefined ? { restore: prior } : {}),
+      status: ALLOWED,
+    });
     changes.push({ kind: "create-view", view: v, ...schemaSpread(v.schema), status: ALLOWED });
   }
 }

package/src/diff/status.ts

@@ -57,10 +57,38 @@ function blockedReasonFor(
       return allow.dropFk ? null : "destructive: drop-fk not allowed (pass allow.dropFk)";
     case "drop-check":
       return allow.dropCheck ? null : "destructive: drop-check not allowed (pass allow.dropCheck)";
-    case "drop-view":
+    case "drop-view": {
+      // A drop that would destroy relations we do NOT manage is gated INDEPENDENTLY of
+      // whether our own view survives. Even the recreate pair — where our view comes
+      // back — cascades through to somebody else's dependent view and destroys it for
+      // good, and this tool cannot restore what it does not manage. So check dependents
+      // FIRST: it is the one thing `allow.dropView` must never be able to wave through.
+      const external = c.dependents ?? [];
+      if (external.length > 0 && !allow.dropViewCascade) {
+        return `destructive: dropping view "${c.view}" would CASCADE into ${external.length} object(s) `
+          + `MetaObjects does not manage and cannot restore `
+          + `(${external.map((d) => `${d.schema}.${d.name}`).join(", ")}) `
+          + `— pass allow.dropViewCascade to destroy them, or migrate them off this view first`;
+      }
       // Identity, not bare name — see viewIdentity().
       if (recreatedViews.has(viewIdentity(c.view, c.schema))) return null; // recreate pair — view survives
       return allow.dropView ? null : "destructive: drop-view not allowed (pass allow.dropView)";
+    }
+
+    case "replace-view":
+      // The DB view carries no MetaObjects fingerprint, so it is either hand-written or
+      // predates fingerprinting — and Postgres deparses view SQL, so the two are
+      // indistinguishable. Overwriting a hand-written view destroys SQL no down
+      // migration can recover, so fail closed and make the operator say yes.
+      //
+      // Every environment upgrading from a pre-fingerprint toolchain hits this exactly
+      // once, then its views are stamped and it never fires again.
+      if (c.unmanagedActual && !allow.adoptView) {
+        return `existing view "${c.view.name}" carries no MetaObjects fingerprint — it is hand-written, `
+          + `or was created before view fingerprinting. Overwriting it takes ownership and cannot be undone. `
+          + `Pass allow.adoptView to adopt it`;
+      }
+      return null;
 
     case "change-column-type":
       if (isWidening(c.from, c.to)) return null;     // widening always allowed
@@ -83,7 +111,6 @@ function blockedReasonFor(
     case "add-fk":
     case "add-check":
     case "create-view":
-    case "replace-view":
       return null;
   }
 }

package/src/drift/drift.ts

@@ -37,9 +37,9 @@ export interface ComputeDriftOptions {
   /**
    * Expected views (projection → CREATE VIEW body), computed by the caller via
    * codegen-ts's `buildProjectionViews`. migrate-ts no longer generates view DDL
-   * itself; pass these so view-body drift is detected. Defaults to none.
+   * itself; pass these so view drift is detected. Defaults to none.
    */
-  views?: readonly import("../types.js").ViewDescriptor[];
+  views?: readonly import("../expected-schema.js").ExpectedViewInput[];
 }
 
 /**

package/src/emit/postgres.ts

@@ -4,6 +4,8 @@ import type {
 } from "../types.js";
 import type { SqlType } from "../sql-type.js";
 import { DEFAULT_DB_SCHEMA_POSTGRES } from "@metaobjectsdev/metadata";
+import { renderFingerprintMarker, viewFingerprint } from "../view-fingerprint.js";
+import { viewReplaceIsLegal } from "../view-column-types.js";
 
 // Stages run low → high. drop-view + drop-fk run BEFORE drop-table so a view
 // that depends on a soon-to-be-dropped table is removed first. create-view
@@ -69,7 +71,7 @@ function renderUp(c: Change): string {
     case "add-check":              return `ALTER TABLE ${quoteQualified(c.table, c.schema)} ADD CONSTRAINT ${quote(c.check.name)} CHECK (${c.check.expression});`;
     case "drop-check":             return `ALTER TABLE ${quoteQualified(c.table, c.schema)} DROP CONSTRAINT ${quote(c.check)};`;
     case "create-view":            return renderCreateView(c.view, c.schema, /* orReplace */ false);
-    case "drop-view":              return `DROP VIEW ${quoteQualifiedView(c.view, c.schema)};`;
+    case "drop-view":              return renderDropView(c);
     case "replace-view":           return renderCreateView(c.view, c.schema, /* orReplace */ true);
   }
 }
@@ -128,8 +130,9 @@ function renderDown(c: Change): string {
         ? `ALTER TABLE ${quoteQualified(c.table, c.schema)} ADD CONSTRAINT ${quote(c.restore.name)} CHECK (${c.restore.expression});`
         : `-- WARNING: down migration cannot restore the original CHECK definition`;
     case "create-view":            return `DROP VIEW ${quoteQualifiedView(c.view.name, c.schema)};`;
-    case "drop-view":              return `-- WARNING: down migration cannot restore the original view definition`;
-    case "replace-view":           return `-- WARNING: down migration cannot restore the original view definition`;
+    // The deparsed body introspection captured IS a valid restore payload.
+    case "drop-view":              return renderRestoreView(c.restore, c.view, c.schema);
+    case "replace-view":           return renderRestoreView(c.restore, c.view.name, c.schema, c.view);
   }
 }
 
@@ -283,10 +286,105 @@ function quoteQualifiedView(view: string, schema: string | undefined): string {
   return quoteQualified(view, schema);
 }
 
+/**
+ * Emit the view AND stamp it with the fingerprint of the body we just wrote.
+ *
+ * The stamp is not decoration — it is the ONLY way a later migrate can tell whether
+ * this view is up to date. Postgres does not store view SQL (it deparses it from the
+ * parse tree), so the text can never be read back and compared; the fingerprint in the
+ * view's COMMENT can. Drop the stamp and every migrate re-proposes every view forever.
+ *
+ * `CREATE OR REPLACE VIEW` does NOT clear an existing comment, so re-stamping on every
+ * replace is both required (the body changed → the hash changed) and sufficient.
+ */
 function renderCreateView(v: ViewDescriptor, schema: string | undefined, orReplace: boolean): string {
   if (v.sql === undefined || v.sql.trim().length === 0) {
     throw new Error(`view "${v.name}" has no sql body — buildExpectedSchema must populate it before emit`);
   }
   const prefix = orReplace ? "CREATE OR REPLACE VIEW" : "CREATE VIEW";
-  return `${prefix} ${quoteQualifiedView(v.name, schema)} AS\n${v.sql};`;
+  const qualified = quoteQualifiedView(v.name, schema);
+  const create = `${prefix} ${qualified} AS\n${v.sql};`;
+  const fingerprint = v.fingerprint ?? viewFingerprint(v.sql);
+  return `${create}\n${renderViewComment(qualified, renderFingerprintMarker(fingerprint))}`;
+}
+
+function renderViewComment(qualifiedView: string, comment: string | null): string {
+  if (comment === null) return `COMMENT ON VIEW ${qualifiedView} IS NULL;`;
+  return `COMMENT ON VIEW ${qualifiedView} IS '${comment.replace(/'/g, "''")}';`;
+}
+
+/**
+ * DROP VIEW, plus — when the drop would cascade into relations we do not manage — a
+ * banner naming every one of them.
+ *
+ * The banner lives in the emitted SQL rather than only in CLI output on purpose: the
+ * migration file is committed and code-reviewed, and "this statement destroys three
+ * objects belonging to another application" is exactly the thing a reviewer must see.
+ *
+ * CASCADE is emitted ONLY when explicitly allowed. Otherwise a plain DROP VIEW is
+ * emitted even if dependents are known — so if a dependent appeared between introspect
+ * and apply, Postgres itself refuses the drop rather than silently destroying it.
+ */
+function renderDropView(c: Extract<Change, { kind: "drop-view" }>): string {
+  const qualified = quoteQualifiedView(c.view, c.schema);
+  const dependents = c.dependents ?? [];
+  if (dependents.length === 0) return `DROP VIEW ${qualified};`;
+
+  const listed = dependents
+    .map((d) => `--   ${d.schema}.${d.name} (${d.relkind === "m" ? "materialized view" : "view"})`)
+    .join("\n");
+  const rule = "-- " + "=".repeat(74);
+  return [
+    rule,
+    "-- WARNING: CASCADE DROP. The following dependent objects are DESTROYED by this",
+    "-- statement. MetaObjects does not manage them and the down migration does NOT",
+    "-- restore them:",
+    listed,
+    rule,
+    `DROP VIEW ${qualified} CASCADE;`,
+  ].join("\n");
+}
+
+/**
+ * Restore a view the up migration dropped or replaced.
+ *
+ * The payload is Postgres's own deparsed body (`pg_get_viewdef`) — useless for
+ * COMPARISON, but perfectly valid SQL that reproduces the view. So the thing that made
+ * the bug (the deparser) is what makes down migrations restorable. The prior stamp is
+ * replayed verbatim: the restored parse tree IS the pre-migration view, so its old
+ * fingerprint is still the truthful one.
+ */
+function renderRestoreView(
+  restore: ViewDescriptor | undefined,
+  name: string,
+  schema: string | undefined,
+  /** The view the UP migration left in place — i.e. what the down is replacing. */
+  current?: ViewDescriptor,
+): string {
+  if (restore?.sql === undefined || restore.sql.trim().length === 0) {
+    return `-- WARNING: down migration cannot restore the original view definition`;
+  }
+  const qualified = quoteQualifiedView(name, schema);
+  const body = restore.sql.trim().replace(/;\s*$/, "");
+
+  // Postgres's OR-REPLACE prefix rule applies to the down migration too, and usually
+  // REFUSES: undoing an appended field means REMOVING a view column, and
+  // `CREATE OR REPLACE VIEW` cannot drop columns ("cannot drop columns from view").
+  // So ask the same question the forward path asks, with the arguments swapped — and
+  // fall back to DROP + CREATE when the answer is no.
+  //
+  // The fallback DROP is deliberately NOT `CASCADE`: if a dependent has since been built
+  // on the newer shape, Postgres refuses the down migration rather than silently
+  // destroying that dependent. Loud beats convenient.
+  const stamp = restore.fingerprint !== undefined
+    ? renderViewComment(qualified, renderFingerprintMarker(restore.fingerprint))
+    // The view being restored carried NO fingerprint (hand-written, or pre-stamping).
+    // Clear ours — otherwise the restored view would advertise a stamp for a body it
+    // does not have, and the next migrate would believe the stamp and skip it.
+    : renderViewComment(qualified, null);
+
+  if (current !== undefined && !viewReplaceIsLegal(restore.columns, current.columns)) {
+    return `DROP VIEW ${qualified};\nCREATE VIEW ${qualified} AS\n${body};\n${stamp}`;
+  }
+  return `CREATE OR REPLACE VIEW ${qualified} AS\n${body};\n${stamp}`;
 }

package/src/expected-schema.ts

@@ -59,6 +59,8 @@ import type {
   Dialect, SchemaSnapshot, TableDescriptor, ColumnDescriptor, IndexDescriptor, FkDescriptor,
   CheckDescriptor, ViewDescriptor,
 } from "./types.js";
+import { viewFingerprint } from "./view-fingerprint.js";
+import { resolveViewColumns, type ExpectedViewColumnInput } from "./view-column-types.js";
 import {
   resolveReferentialActions,
   validateSetNullNullability,
@@ -89,8 +91,25 @@ export interface BuildExpectedSchemaOptions {
    * generate view DDL itself (it stays dependency-pure — never importing the
    * code generator); view SQL has a single source, `emitViewDdl` in codegen-ts.
    * Defaults to none.
+   *
+   * The caller supplies each view's output columns PHYSICALLY but untyped
+   * (codegen-ts knows nothing of SqlType); Pass 4 resolves them against the
+   * expected tables and computes the view's fingerprint.
    */
-  views?: readonly ViewDescriptor[];
+  views?: readonly ExpectedViewInput[];
+}
+
+/**
+ * A view as the caller (codegen-ts `buildProjectionViews`) produces it — structurally
+ * an `ExpectedView`. It becomes a full `ViewDescriptor` in Pass 4, which is where the
+ * fingerprint is computed and the column types are resolved.
+ */
+export interface ExpectedViewInput {
+  name: string;
+  schema?: string;
+  sql?: string;
+  dependsOn?: readonly string[];
+  columns?: readonly ExpectedViewColumnInput[];
 }
 
 export function buildExpectedSchema(
@@ -209,7 +228,24 @@ export function buildExpectedSchema(
   // Pass 4: views from read-only projections — supplied by the caller (computed
   // via codegen-ts's buildProjectionViews, the single view-SQL source). migrate-ts
   // never generates view DDL itself, keeping it free of a codegen-ts dependency.
-  const views = (opts?.views ?? []) as ViewDescriptor[];
+  //
+  // Two things are derived here rather than by the caller:
+  //   - the FINGERPRINT, a hash of the generated body. It is the only sound way to
+  //     compare a view against Postgres, which deparses view SQL and so can never
+  //     hand back the text we wrote (see view-fingerprint.ts). Computed here so the
+  //     producer and the parser of the marker live in one package.
+  //   - the column SQL TYPES, resolved against the tables built above. They decide
+  //     whether a view change can use a non-destructive CREATE OR REPLACE.
+  const views: ViewDescriptor[] = (opts?.views ?? []).map((v) => {
+    const columns = resolveViewColumns(v.columns, tables);
+    return {
+      name: v.name,
+      ...(v.schema !== undefined ? { schema: v.schema } : {}),
+      ...(v.sql !== undefined ? { sql: v.sql, fingerprint: viewFingerprint(v.sql) } : {}),
+      ...(v.dependsOn !== undefined ? { dependsOn: v.dependsOn } : {}),
+      ...(columns !== undefined ? { columns } : {}),
+    };
+  });
 
   return { tables, views };
 }
@@ -928,8 +964,13 @@ function subtypeToSqlType(field: MetaData): SqlType {
       if (typeof precision === "number" && typeof scale === "number") {
         return { kind: "numeric", precision, scale };
       }
+      // NUMERIC(p) IS NUMERIC(p,0) — the SQL standard defaults an omitted scale
+      // to zero, and Postgres stores it that way (information_schema reports
+      // numeric_scale = 0, not NULL). Model the scale the database will actually
+      // hold, or expected (bare p) and introspected (p, 0) can never converge and
+      // the column churns change-column-type on every migrate.
       if (typeof precision === "number") {
-        return { kind: "numeric", precision };
+        return { kind: "numeric", precision, scale: 0 };
       }
       return { kind: "numeric" };
     }