chore(deps): bump the metaobjects group with 6 updates

[dependabot]

Bumps the metaobjects group with 6 updates:

Package	From	To
@metaobjectsdev/cli	0.20.3	0.20.9
@metaobjectsdev/codegen-ts	0.20.3	0.20.9
@metaobjectsdev/render	0.20.3	0.20.9
@metaobjectsdev/runtime-ts	0.20.3	0.20.9
@metaobjectsdev/sdk	0.20.3	0.20.9
@metaobjectsdev/metadata	0.20.3	0.20.9

Updates @metaobjectsdev/cli from 0.20.3 to 0.20.9

Release notes

Sourced from @​metaobjectsdev/cli's releases.

0.20.9 — cross-package reference binding + dependent-view rebuild (#243, #244)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged). Fixes found while hardening the D1 migrate path.

#244 — cross-package references bind by fully-qualified name. When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via silently bound the wrong package's entity, load-order-dependent — a foreign key against the wrong table (silent) and/or a projection view whose JOIN read the wrong table (fails at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve package-aware via the loader's resolveObjectRef/resolutionKey() contract. Generated view SQL is byte-identical for existing single-package models. Plus a build-time ERR_DUPLICATE_SQL_NAME guard when two distinct objects generate the same database name.

#243 — a dependent view over a rebuilt table is no longer stranded. On SQLite/D1 a table rebuilt for a CHECK/FK/enum-@values change (or pulled into the D1 FK-cascade as a referrer) left a view reading it dangling across the DROP/RENAME, failing at apply. The diff now drops/recreates dependent views for the full recreate-trigger class, and the D1 cascade owns the view drop/recreate in-order (no double-emit). Postgres unaffected.

Each half reproduced on a real engine before fixing. See CHANGELOG.md [0.20.9].

0.20.8 — D1 FK-cascade auto-fix (#241)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged — D1 is a TS-only dialect).

D1 auto-cascade for rebuilding foreign-key-referenced tables (#241). meta migrate --dialect d1 no longer refuses when a change would rebuild a table another table's foreign key references (#226) — it auto-generates an appliable cascade: the referenced table and every table that transitively references it are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON, so every FK check defers to the end of D1's implicit transaction. Built over the union of the actual and expected FK graphs, closing #226's residual under-refuse gap (a single migration that both rebuilds a referenced table and drops the referencing FK). Multi-table FK cycles are still refused; self-references are handled. Output is byte-identical for any migration that does not rebuild an FK-referenced table.

Verified by a libSQL real-engine gate (one-transaction = remote-D1 model) across all topologies + the #226 gap + a mixed-migration splice + cycle refusal, each asserting applies-cleanly, row data intact, FK re-enforced, and a re-diff EMPTY.

See CHANGELOG.md [0.20.8]. Follow-up: #243 (dependent-view/Pass-2c interaction).

Changelog

Sourced from @​metaobjectsdev/cli's changelog.

[0.20.9] — 2026-07-28

npm-only — migrate-ts + codegen-ts (schema migrations and projection-view codegen are TS-owned, ADR-0015); PyPI / NuGet / Maven Central are unchanged.

Fixed — a projection/view over a rebuilt table is no longer stranded mid-migration (#243)

On SQLite and Cloudflare D1, a table is rebuilt via recreate-and-copy (DROP + RENAME) not only for column changes but also for CHECK / foreign-key / evolved field.enum @values changes — and, on D1, for any table pulled into the FK-cascade as a referrer. A view reading that table was left dangling across the rebuild, so the migration failed at apply time (error in view …: no such table …). The diff now drops a dependent view before the rebuild and recreates it after for the CHECK/FK/enum-values class too (previously only column-altering changes triggered it), and the D1 cascade drops/recreates every view over an affected table in the correct order — no double-emit. Postgres is unaffected (FK/CHECK changes there are ALTER … ADD/DROP CONSTRAINT, no table rebuild).

Fixed — cross-package references bind by fully-qualified name; duplicate generated SQL names are refused (#244)

When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via did not reliably bind the qualified target — the package qualifier was discarded and the bare name resolved against a global slot, so which entity won depended on metadata file load order. This produced a silent wrong-table foreign key (the serious case: no error, an FK against the wrong table) and/or an invalid projection view whose SELECT/JOIN read the wrong package's table (column … does not exist at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve object references package-aware via the loader's resolveObjectRef / resolutionKey() contract — an FQN binds exactly, a bare ref binds the referrer's own package then a root-level object, and an ambiguous bare name resolves to nothing rather than guessing. Generated view SQL (aliases, column order) is byte-identical for existing single-package models. Separately, two distinct metadata objects that generate the same database name (schema-qualified — table/table, view/view, or table/view, across packages) now fail at build time with ERR_DUPLICATE_SQL_NAME naming both owners, instead of emitting an un-appliable migration the database would reject.

[0.20.8] — 2026-07-28

npm-only — the changed code is all in migrate-ts (D1 is a TS-only dialect); PyPI / NuGet / Maven Central are unchanged.

Added — D1 auto-cascade for rebuilding foreign-key-referenced tables (#241)

npm-only (migrate-ts — D1 is a TS-only dialect). meta migrate --dialect d1 no longer refuses when a change would rebuild a table that another table's foreign key references (#226) — it now auto-generates an appliable cascade instead. The emitter rebuilds the referenced table together with every table that transitively references it, in one pass: the affected tables are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON so every foreign-key check defers to the end of D1's implicit

... (truncated)

Commits

• 6146ec5 chore(release): 0.20.9
• f0a3fd9 chore(release): 0.20.8
• 9556756 feat(#241): thread actualSchema through emit() to the d1 emitter
• 2ffa8c4 chore(release): 0.20.7
• 46d14df docs/polish(#242): precise apply-pending vs --apply wording; usage synopsis; ...
• 4a051e8 feat(#242): meta migrate apply-pending — replay committed migrations
• 2ac18e5 feat(#242): parse the migrate apply-pending subcommand
• b706467 chore(release): 0.20.6 / 0.19.8 / 7.11.6 / 0.19.6
• 2b81079 chore(release): 0.20.5 / 0.19.7 / 7.11.5 / 0.19.5
• 61c1628 chore(release): 0.20.4 (npm)
• See full diff in compare view

Updates @metaobjectsdev/codegen-ts from 0.20.3 to 0.20.9

Release notes

Sourced from @​metaobjectsdev/codegen-ts's releases.

0.20.9 — cross-package reference binding + dependent-view rebuild (#243, #244)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged). Fixes found while hardening the D1 migrate path.

#244 — cross-package references bind by fully-qualified name. When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via silently bound the wrong package's entity, load-order-dependent — a foreign key against the wrong table (silent) and/or a projection view whose JOIN read the wrong table (fails at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve package-aware via the loader's resolveObjectRef/resolutionKey() contract. Generated view SQL is byte-identical for existing single-package models. Plus a build-time ERR_DUPLICATE_SQL_NAME guard when two distinct objects generate the same database name.

#243 — a dependent view over a rebuilt table is no longer stranded. On SQLite/D1 a table rebuilt for a CHECK/FK/enum-@values change (or pulled into the D1 FK-cascade as a referrer) left a view reading it dangling across the DROP/RENAME, failing at apply. The diff now drops/recreates dependent views for the full recreate-trigger class, and the D1 cascade owns the view drop/recreate in-order (no double-emit). Postgres unaffected.

Each half reproduced on a real engine before fixing. See CHANGELOG.md [0.20.9].

0.20.8 — D1 FK-cascade auto-fix (#241)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged — D1 is a TS-only dialect).

D1 auto-cascade for rebuilding foreign-key-referenced tables (#241). meta migrate --dialect d1 no longer refuses when a change would rebuild a table another table's foreign key references (#226) — it auto-generates an appliable cascade: the referenced table and every table that transitively references it are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON, so every FK check defers to the end of D1's implicit transaction. Built over the union of the actual and expected FK graphs, closing #226's residual under-refuse gap (a single migration that both rebuilds a referenced table and drops the referencing FK). Multi-table FK cycles are still refused; self-references are handled. Output is byte-identical for any migration that does not rebuild an FK-referenced table.

Verified by a libSQL real-engine gate (one-transaction = remote-D1 model) across all topologies + the #226 gap + a mixed-migration splice + cycle refusal, each asserting applies-cleanly, row data intact, FK re-enforced, and a re-diff EMPTY.

See CHANGELOG.md [0.20.8]. Follow-up: #243 (dependent-view/Pass-2c interaction).

Changelog

Sourced from @​metaobjectsdev/codegen-ts's changelog.

[0.20.9] — 2026-07-28

npm-only — migrate-ts + codegen-ts (schema migrations and projection-view codegen are TS-owned, ADR-0015); PyPI / NuGet / Maven Central are unchanged.

Fixed — a projection/view over a rebuilt table is no longer stranded mid-migration (#243)

On SQLite and Cloudflare D1, a table is rebuilt via recreate-and-copy (DROP + RENAME) not only for column changes but also for CHECK / foreign-key / evolved field.enum @values changes — and, on D1, for any table pulled into the FK-cascade as a referrer. A view reading that table was left dangling across the rebuild, so the migration failed at apply time (error in view …: no such table …). The diff now drops a dependent view before the rebuild and recreates it after for the CHECK/FK/enum-values class too (previously only column-altering changes triggered it), and the D1 cascade drops/recreates every view over an affected table in the correct order — no double-emit. Postgres is unaffected (FK/CHECK changes there are ALTER … ADD/DROP CONSTRAINT, no table rebuild).

Fixed — cross-package references bind by fully-qualified name; duplicate generated SQL names are refused (#244)

When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via did not reliably bind the qualified target — the package qualifier was discarded and the bare name resolved against a global slot, so which entity won depended on metadata file load order. This produced a silent wrong-table foreign key (the serious case: no error, an FK against the wrong table) and/or an invalid projection view whose SELECT/JOIN read the wrong package's table (column … does not exist at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve object references package-aware via the loader's resolveObjectRef / resolutionKey() contract — an FQN binds exactly, a bare ref binds the referrer's own package then a root-level object, and an ambiguous bare name resolves to nothing rather than guessing. Generated view SQL (aliases, column order) is byte-identical for existing single-package models. Separately, two distinct metadata objects that generate the same database name (schema-qualified — table/table, view/view, or table/view, across packages) now fail at build time with ERR_DUPLICATE_SQL_NAME naming both owners, instead of emitting an un-appliable migration the database would reject.

[0.20.8] — 2026-07-28

npm-only — the changed code is all in migrate-ts (D1 is a TS-only dialect); PyPI / NuGet / Maven Central are unchanged.

Added — D1 auto-cascade for rebuilding foreign-key-referenced tables (#241)

npm-only (migrate-ts — D1 is a TS-only dialect). meta migrate --dialect d1 no longer refuses when a change would rebuild a table that another table's foreign key references (#226) — it now auto-generates an appliable cascade instead. The emitter rebuilds the referenced table together with every table that transitively references it, in one pass: the affected tables are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON so every foreign-key check defers to the end of D1's implicit

... (truncated)

Commits

• 6146ec5 chore(release): 0.20.9
• 4af1d18 fix(codegen): projection view resolves @from/@via/@​references package-aware (...
• f0a3fd9 chore(release): 0.20.8
• 2ffa8c4 chore(release): 0.20.7
• b706467 chore(release): 0.20.6 / 0.19.8 / 7.11.6 / 0.19.6
• 96401fe fix(#234): resolve adversarial-review cross-port divergences (H1/H2/N1/N2)
• 9cc6328 feat(#234): Stage 2 pt.2 — @​lenient degrade codegen (5 ports)
• 357441f feat(#234): Stage 1 pt.1 — uri/inet strict-contract corpus + TS reference por...
• 2b81079 chore(release): 0.20.5 / 0.19.7 / 7.11.5 / 0.19.5
• 61c1628 chore(release): 0.20.4 (npm)
• See full diff in compare view

Updates @metaobjectsdev/render from 0.20.3 to 0.20.9

Release notes

Sourced from @​metaobjectsdev/render's releases.

0.20.9 — cross-package reference binding + dependent-view rebuild (#243, #244)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged). Fixes found while hardening the D1 migrate path.

#244 — cross-package references bind by fully-qualified name. When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via silently bound the wrong package's entity, load-order-dependent — a foreign key against the wrong table (silent) and/or a projection view whose JOIN read the wrong table (fails at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve package-aware via the loader's resolveObjectRef/resolutionKey() contract. Generated view SQL is byte-identical for existing single-package models. Plus a build-time ERR_DUPLICATE_SQL_NAME guard when two distinct objects generate the same database name.

#243 — a dependent view over a rebuilt table is no longer stranded. On SQLite/D1 a table rebuilt for a CHECK/FK/enum-@values change (or pulled into the D1 FK-cascade as a referrer) left a view reading it dangling across the DROP/RENAME, failing at apply. The diff now drops/recreates dependent views for the full recreate-trigger class, and the D1 cascade owns the view drop/recreate in-order (no double-emit). Postgres unaffected.

Each half reproduced on a real engine before fixing. See CHANGELOG.md [0.20.9].

0.20.8 — D1 FK-cascade auto-fix (#241)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged — D1 is a TS-only dialect).

D1 auto-cascade for rebuilding foreign-key-referenced tables (#241). meta migrate --dialect d1 no longer refuses when a change would rebuild a table another table's foreign key references (#226) — it auto-generates an appliable cascade: the referenced table and every table that transitively references it are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON, so every FK check defers to the end of D1's implicit transaction. Built over the union of the actual and expected FK graphs, closing #226's residual under-refuse gap (a single migration that both rebuilds a referenced table and drops the referencing FK). Multi-table FK cycles are still refused; self-references are handled. Output is byte-identical for any migration that does not rebuild an FK-referenced table.

Verified by a libSQL real-engine gate (one-transaction = remote-D1 model) across all topologies + the #226 gap + a mixed-migration splice + cycle refusal, each asserting applies-cleanly, row data intact, FK re-enforced, and a re-diff EMPTY.

See CHANGELOG.md [0.20.8]. Follow-up: #243 (dependent-view/Pass-2c interaction).

Changelog

Sourced from @​metaobjectsdev/render's changelog.

[0.20.9] — 2026-07-28

npm-only — migrate-ts + codegen-ts (schema migrations and projection-view codegen are TS-owned, ADR-0015); PyPI / NuGet / Maven Central are unchanged.

Fixed — a projection/view over a rebuilt table is no longer stranded mid-migration (#243)

On SQLite and Cloudflare D1, a table is rebuilt via recreate-and-copy (DROP + RENAME) not only for column changes but also for CHECK / foreign-key / evolved field.enum @values changes — and, on D1, for any table pulled into the FK-cascade as a referrer. A view reading that table was left dangling across the rebuild, so the migration failed at apply time (error in view …: no such table …). The diff now drops a dependent view before the rebuild and recreates it after for the CHECK/FK/enum-values class too (previously only column-altering changes triggered it), and the D1 cascade drops/recreates every view over an affected table in the correct order — no double-emit. Postgres is unaffected (FK/CHECK changes there are ALTER … ADD/DROP CONSTRAINT, no table rebuild).

Fixed — cross-package references bind by fully-qualified name; duplicate generated SQL names are refused (#244)

When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via did not reliably bind the qualified target — the package qualifier was discarded and the bare name resolved against a global slot, so which entity won depended on metadata file load order. This produced a silent wrong-table foreign key (the serious case: no error, an FK against the wrong table) and/or an invalid projection view whose SELECT/JOIN read the wrong package's table (column … does not exist at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve object references package-aware via the loader's resolveObjectRef / resolutionKey() contract — an FQN binds exactly, a bare ref binds the referrer's own package then a root-level object, and an ambiguous bare name resolves to nothing rather than guessing. Generated view SQL (aliases, column order) is byte-identical for existing single-package models. Separately, two distinct metadata objects that generate the same database name (schema-qualified — table/table, view/view, or table/view, across packages) now fail at build time with ERR_DUPLICATE_SQL_NAME naming both owners, instead of emitting an un-appliable migration the database would reject.

[0.20.8] — 2026-07-28

npm-only — the changed code is all in migrate-ts (D1 is a TS-only dialect); PyPI / NuGet / Maven Central are unchanged.

Added — D1 auto-cascade for rebuilding foreign-key-referenced tables (#241)

npm-only (migrate-ts — D1 is a TS-only dialect). meta migrate --dialect d1 no longer refuses when a change would rebuild a table that another table's foreign key references (#226) — it now auto-generates an appliable cascade instead. The emitter rebuilds the referenced table together with every table that transitively references it, in one pass: the affected tables are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON so every foreign-key check defers to the end of D1's implicit

... (truncated)

Commits

• 6146ec5 chore(release): 0.20.9
• f0a3fd9 chore(release): 0.20.8
• 2ffa8c4 chore(release): 0.20.7
• b706467 chore(release): 0.20.6 / 0.19.8 / 7.11.6 / 0.19.6
• 2b81079 chore(release): 0.20.5 / 0.19.7 / 7.11.5 / 0.19.5
• 61c1628 chore(release): 0.20.4 (npm)
• See full diff in compare view

Updates @metaobjectsdev/runtime-ts from 0.20.3 to 0.20.9

Release notes

Sourced from @​metaobjectsdev/runtime-ts's releases.

0.20.9 — cross-package reference binding + dependent-view rebuild (#243, #244)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged). Fixes found while hardening the D1 migrate path.

#244 — cross-package references bind by fully-qualified name. When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via silently bound the wrong package's entity, load-order-dependent — a foreign key against the wrong table (silent) and/or a projection view whose JOIN read the wrong table (fails at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve package-aware via the loader's resolveObjectRef/resolutionKey() contract. Generated view SQL is byte-identical for existing single-package models. Plus a build-time ERR_DUPLICATE_SQL_NAME guard when two distinct objects generate the same database name.

#243 — a dependent view over a rebuilt table is no longer stranded. On SQLite/D1 a table rebuilt for a CHECK/FK/enum-@values change (or pulled into the D1 FK-cascade as a referrer) left a view reading it dangling across the DROP/RENAME, failing at apply. The diff now drops/recreates dependent views for the full recreate-trigger class, and the D1 cascade owns the view drop/recreate in-order (no double-emit). Postgres unaffected.

Each half reproduced on a real engine before fixing. See CHANGELOG.md [0.20.9].

0.20.8 — D1 FK-cascade auto-fix (#241)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged — D1 is a TS-only dialect).

D1 auto-cascade for rebuilding foreign-key-referenced tables (#241). meta migrate --dialect d1 no longer refuses when a change would rebuild a table another table's foreign key references (#226) — it auto-generates an appliable cascade: the referenced table and every table that transitively references it are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON, so every FK check defers to the end of D1's implicit transaction. Built over the union of the actual and expected FK graphs, closing #226's residual under-refuse gap (a single migration that both rebuilds a referenced table and drops the referencing FK). Multi-table FK cycles are still refused; self-references are handled. Output is byte-identical for any migration that does not rebuild an FK-referenced table.

Verified by a libSQL real-engine gate (one-transaction = remote-D1 model) across all topologies + the #226 gap + a mixed-migration splice + cycle refusal, each asserting applies-cleanly, row data intact, FK re-enforced, and a re-diff EMPTY.

See CHANGELOG.md [0.20.8]. Follow-up: #243 (dependent-view/Pass-2c interaction).

Changelog

Sourced from @​metaobjectsdev/runtime-ts's changelog.

[0.20.9] — 2026-07-28

npm-only — migrate-ts + codegen-ts (schema migrations and projection-view codegen are TS-owned, ADR-0015); PyPI / NuGet / Maven Central are unchanged.

Fixed — a projection/view over a rebuilt table is no longer stranded mid-migration (#243)

On SQLite and Cloudflare D1, a table is rebuilt via recreate-and-copy (DROP + RENAME) not only for column changes but also for CHECK / foreign-key / evolved field.enum @values changes — and, on D1, for any table pulled into the FK-cascade as a referrer. A view reading that table was left dangling across the rebuild, so the migration failed at apply time (error in view …: no such table …). The diff now drops a dependent view before the rebuild and recreates it after for the CHECK/FK/enum-values class too (previously only column-altering changes triggered it), and the D1 cascade drops/recreates every view over an affected table in the correct order — no double-emit. Postgres is unaffected (FK/CHECK changes there are ALTER … ADD/DROP CONSTRAINT, no table rebuild).

Fixed — cross-package references bind by fully-qualified name; duplicate generated SQL names are refused (#244)

When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via did not reliably bind the qualified target — the package qualifier was discarded and the bare name resolved against a global slot, so which entity won depended on metadata file load order. This produced a silent wrong-table foreign key (the serious case: no error, an FK against the wrong table) and/or an invalid projection view whose SELECT/JOIN read the wrong package's table (column … does not exist at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve object references package-aware via the loader's resolveObjectRef / resolutionKey() contract — an FQN binds exactly, a bare ref binds the referrer's own package then a root-level object, and an ambiguous bare name resolves to nothing rather than guessing. Generated view SQL (aliases, column order) is byte-identical for existing single-package models. Separately, two distinct metadata objects that generate the same database name (schema-qualified — table/table, view/view, or table/view, across packages) now fail at build time with ERR_DUPLICATE_SQL_NAME naming both owners, instead of emitting an un-appliable migration the database would reject.

[0.20.8] — 2026-07-28

npm-only — the changed code is all in migrate-ts (D1 is a TS-only dialect); PyPI / NuGet / Maven Central are unchanged.

Added — D1 auto-cascade for rebuilding foreign-key-referenced tables (#241)

npm-only (migrate-ts — D1 is a TS-only dialect). meta migrate --dialect d1 no longer refuses when a change would rebuild a table that another table's foreign key references (#226) — it now auto-generates an appliable cascade instead. The emitter rebuilds the referenced table together with every table that transitively references it, in one pass: the affected tables are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON so every foreign-key check defers to the end of D1's implicit

... (truncated)

Commits

• 6146ec5 chore(release): 0.20.9
• f0a3fd9 chore(release): 0.20.8
• 2ffa8c4 chore(release): 0.20.7
• b706467 chore(release): 0.20.6 / 0.19.8 / 7.11.6 / 0.19.6
• 2b81079 chore(release): 0.20.5 / 0.19.7 / 7.11.5 / 0.19.5
• 61c1628 chore(release): 0.20.4 (npm)
• See full diff in compare view

Updates @metaobjectsdev/sdk from 0.20.3 to 0.20.9

Release notes

Sourced from @​metaobjectsdev/sdk's releases.

0.20.9 — cross-package reference binding + dependent-view rebuild (#243, #244)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged). Fixes found while hardening the D1 migrate path.

#244 — cross-package references bind by fully-qualified name. When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via silently bound the wrong package's entity, load-order-dependent — a foreign key against the wrong table (silent) and/or a projection view whose JOIN read the wrong table (fails at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve package-aware via the loader's resolveObjectRef/resolutionKey() contract. Generated view SQL is byte-identical for existing single-package models. Plus a build-time ERR_DUPLICATE_SQL_NAME guard when two distinct objects generate the same database name.

#243 — a dependent view over a rebuilt table is no longer stranded. On SQLite/D1 a table rebuilt for a CHECK/FK/enum-@values change (or pulled into the D1 FK-cascade as a referrer) left a view reading it dangling across the DROP/RENAME, failing at apply. The diff now drops/recreates dependent views for the full recreate-trigger class, and the D1 cascade owns the view drop/recreate in-order (no double-emit). Postgres unaffected.

Each half reproduced on a real engine before fixing. See CHANGELOG.md [0.20.9].

0.20.8 — D1 FK-cascade auto-fix (#241)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged — D1 is a TS-only dialect).

D1 auto-cascade for rebuilding foreign-key-referenced tables (#241). meta migrate --dialect d1 no longer refuses when a change would rebuild a table another table's foreign key references (#226) — it auto-generates an appliable cascade: the referenced table and every table that transitively references it are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON, so every FK check defers to the end of D1's implicit transaction. Built over the union of the actual and expected FK graphs, closing #226's residual under-refuse gap (a single migration that both rebuilds a referenced table and drops the referencing FK). Multi-table FK cycles are still refused; self-references are handled. Output is byte-identical for any migration that does not rebuild an FK-referenced table.

Verified by a libSQL real-engine gate (one-transaction = remote-D1 model) across all topologies + the #226 gap + a mixed-migration splice + cycle refusal, each asserting applies-cleanly, row data intact, FK re-enforced, and a re-diff EMPTY.

See CHANGELOG.md [0.20.8]. Follow-up: #243 (dependent-view/Pass-2c interaction).

Changelog

Sourced from @​metaobjectsdev/sdk's changelog.

[0.20.9] — 2026-07-28

npm-only — migrate-ts + codegen-ts (schema migrations and projection-view codegen are TS-owned, ADR-0015); PyPI / NuGet / Maven Central are unchanged.

Fixed — a projection/view over a rebuilt table is no longer stranded mid-migration (#243)

On SQLite and Cloudflare D1, a table is rebuilt via recreate-and-copy (DROP + RENAME) not only for column changes but also for CHECK / foreign-key / evolved field.enum @values changes — and, on D1, for any table pulled into the FK-cascade as a referrer. A view reading that table was left dangling across the rebuild, so the migration failed at apply time (error in view …: no such table …). The diff now drops a dependent view before the rebuild and recreates it after for the CHECK/FK/enum-values class too (previously only column-altering changes triggered it), and the D1 cascade drops/recreates every view over an affected table in the correct order — no double-emit. Postgres is unaffected (FK/CHECK changes there are ALTER … ADD/DROP CONSTRAINT, no table rebuild).

Fixed — cross-package references bind by fully-qualified name; duplicate generated SQL names are refused (#244)

When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via did not reliably bind the qualified target — the package qualifier was discarded and the bare name resolved against a global slot, so which entity won depended on metadata file load order. This produced a silent wrong-table foreign key (the serious case: no error, an FK against the wrong table) and/or an invalid projection view whose SELECT/JOIN read the wrong package's table (column … does not exist at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve object references package-aware via the loader's resolveObjectRef / resolutionKey() contract — an FQN binds exactly, a bare ref binds the referrer's own package then a root-level object, and an ambiguous bare name resolves to nothing rather than guessing. Generated view SQL (aliases, column order) is byte-identical for existing single-package models. Separately, two distinct metadata objects that generate the same database name (schema-qualified — table/table, view/view, or table/view, across packages) now fail at build time with ERR_DUPLICATE_SQL_NAME naming both owners, instead of emitting an un-appliable migration the database would reject.

[0.20.8] — 2026-07-28

npm-only — the changed code is all in migrate-ts (D1 is a TS-only dialect); PyPI / NuGet / Maven Central are unchanged.

Added — D1 auto-cascade for rebuilding foreign-key-referenced tables (#241)

npm-only (migrate-ts — D1 is a TS-only dialect). meta migrate --dialect d1 no longer refuses when a change would rebuild a table that another table's foreign key references (#226) — it now auto-generates an appliable cascade instead. The emitter rebuilds the referenced table together with every table that transitively references it, in one pass: the affected tables are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON so every foreign-key check defers to the end of D1's implicit

... (truncated)

Commits

• 6146ec5 chore(release): 0.20.9
• f0a3fd9 chore(release): 0.20.8
• 2ffa8c4 chore(release): 0.20.7
• b706467 chore(release): 0.20.6 / 0.19.8 / 7.11.6 / 0.19.6
• 2b81079 chore(release): 0.20.5 / 0.19.7 / 7.11.5 / 0.19.5
• 61c1628 chore(release): 0.20.4 (npm)
• See full diff in compare view

Updates @metaobjectsdev/metadata from 0.20.3 to 0.20.9

Release notes

Sourced from @​metaobjectsdev/metadata's releases.

0.20.9 — cross-package reference binding + dependent-view rebuild (#243, #244)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged). Fixes found while hardening the D1 migrate path.

#244 — cross-package references bind by fully-qualified name. When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via silently bound the wrong package's entity, load-order-dependent — a foreign key against the wrong table (silent) and/or a projection view whose JOIN read the wrong table (fails at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve package-aware via the loader's resolveObjectRef/resolutionKey() contract. Generated view SQL is byte-identical for existing single-package models. Plus a build-time ERR_DUPLICATE_SQL_NAME guard when two distinct objects generate the same database name.

#243 — a dependent view over a rebuilt table is no longer stranded. On SQLite/D1 a table rebuilt for a CHECK/FK/enum-@values change (or pulled into the D1 FK-cascade as a referrer) left a view reading it dangling across the DROP/RENAME, failing at apply. The diff now drops/recreates dependent views for the full recreate-trigger class, and the D1 cascade owns the view drop/recreate in-order (no double-emit). Postgres unaffected.

Each half reproduced on a real engine before fixing. See CHANGELOG.md [0.20.9].

0.20.8 — D1 FK-cascade auto-fix (#241)

npm-only patch (14-package lockstep; PyPI/NuGet/Maven Central unchanged — D1 is a TS-only dialect).

D1 auto-cascade for rebuilding foreign-key-referenced tables (#241). meta migrate --dialect d1 no longer refuses when a change would rebuild a table another table's foreign key references (#226) — it auto-generates an appliable cascade: the referenced table and every table that transitively references it are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON, so every FK check defers to the end of D1's implicit transaction. Built over the union of the actual and expected FK graphs, closing #226's residual under-refuse gap (a single migration that both rebuilds a referenced table and drops the referencing FK). Multi-table FK cycles are still refused; self-references are handled. Output is byte-identical for any migration that does not rebuild an FK-referenced table.

Verified by a libSQL real-engine gate (one-transaction = remote-D1 model) across all topologies + the #226 gap + a mixed-migration splice + cycle refusal, each asserting applies-cleanly, row data intact, FK re-enforced, and a re-diff EMPTY.

See CHANGELOG.md [0.20.8]. Follow-up: #243 (dependent-view/Pass-2c interaction).

Changelog

Sourced from @​metaobjectsdev/metadata's changelog.

[0.20.9] — 2026-07-28

npm-only — migrate-ts + codegen-ts (schema migrations and projection-view codegen are TS-owned, ADR-0015); PyPI / NuGet / Maven Central are unchanged.

Fixed — a projection/view over a rebuilt table is no longer stranded mid-migration (#243)

On SQLite and Cloudflare D1, a table is rebuilt via recreate-and-copy (DROP + RENAME) not only for column changes but also for CHECK / foreign-key / evolved field.enum @values changes — and, on D1, for any table pulled into the FK-cascade as a referrer. A view reading that table was left dangling across the rebuild, so the migration failed at apply time (error in view …: no such table …). The diff now drops a dependent view before the rebuild and recreates it after for the CHECK/FK/enum-values class too (previously only column-altering changes triggered it), and the D1 cascade drops/recreates every view over an affected table in the correct order — no double-emit. Postgres is unaffected (FK/CHECK changes there are ALTER … ADD/DROP CONSTRAINT, no table rebuild).

Fixed — cross-package references bind by fully-qualified name; duplicate generated SQL names are refused (#244)

When two packages declared a same-bare-named object.entity, a fully-qualified @references / projection origin.passthrough @from / @via did not reliably bind the qualified target — the package qualifier was discarded and the bare name resolved against a global slot, so which entity won depended on metadata file load order. This produced a silent wrong-table foreign key (the serious case: no error, an FK against the wrong table) and/or an invalid projection view whose SELECT/JOIN read the wrong package's table (column … does not exist at apply). Both the schema builder (migrate-ts, FK targets) and the projection view-spec (codegen-ts, @from/@via/@of/extends join resolution) now resolve object references package-aware via the loader's resolveObjectRef / resolutionKey() contract — an FQN binds exactly, a bare ref binds the referrer's own package then a root-level object, and an ambiguous bare name resolves to nothing rather than guessing. Generated view SQL (aliases, column order) is byte-identical for existing single-package models. Separately, two distinct metadata objects that generate the same database name (schema-qualified — table/table, view/view, or table/view, across packages) now fail at build time with ERR_DUPLICATE_SQL_NAME naming both owners, instead of emitting an un-appliable migration the database would reject.

[0.20.8] — 2026-07-28

npm-only — the changed code is all in migrate-ts (D1 is a TS-only dialect); PyPI / NuGet / Maven Central are unchanged.

Added — D1 auto-cascade for rebuilding foreign-key-referenced tables (#241)

npm-only (migrate-ts — D1 is a TS-only dialect). meta migrate --dialect d1 no longer refuses when a change would rebuild a table that another table's foreign key references (#226) — it now auto-generates an appliable cascade instead. The emitter rebuilds the referenced table together with every table that transitively references it, in one pass: the affected tables are dropped referrers-first and recreated parents-first, under PRAGMA defer_foreign_keys = ON so every foreign-key check defers to the end of D1's implicit

... (truncated)

Commits

• 6146ec5 chore(release): 0.20.9
• f0a3fd9 chore(release): 0.20.8
• 2ffa8c4 chore(release): 0.20.7
• b706467 chore(release): 0.20.6 / 0.19.8 / 7.11.6 / 0.19.6
• 96401fe fix(#234): resolve adversarial-review cross-port divergences (H1/H2/N1/N2)
• 65aa601 feat(#234): Stage 2 pt.1 — register @​lenient on field.uri/field.inet (5 ports)
• 2b81079 chore(release): 0.20.5 / 0.19.7 / 7.11.5 / 0.19.5