@zerotal/orm 1.6.3 → 1.7.2

package/CHANGELOG.md

@@ -8,6 +8,97 @@ follows the Zerotal monorepo's unified versioning.
 
 ## [Unreleased]
 
+### Fixed
+
+- **A seeder that failed partway left its rows behind.** `Seeder.call()` has always wrapped
+  *composed* seeders in a transaction, so a `DatabaseSeeder` that delegates was atomic and one that
+  does its work inline — which is most of them — was not. A failure on the fourth table committed
+  the first three, so the obvious next move, running it again, died on a unique constraint, and the
+  only way out was `migrate:fresh`. Migrations became transactional in 1.7.0; this closes the
+  asymmetry.
+
+  `db:seed` now wraps the whole run. Nesting is safe — `DB.transaction` opens a `SAVEPOINT` when one
+  is already open, so an inner `call()` still rolls back independently. The wrapper is skipped when
+  no connection is bound, because a seeder is not obliged to touch the database and an app that has
+  not configured one should not fail to seed over a transaction it never needed.
+
+
+### Fixed
+
+- **`DatabaseProvider` now runs in `worker`, so `zt queue:work` can boot.** It did not, and the
+  consequence was total rather than partial: `QueueProvider` _does_ run in `worker`, the
+  queue's own default driver is `sqlite`, and so the worker asked for a connection this
+  provider had not made and died on startup —
+
+  ```
+  error: [Zerotal ORM] No database connection. Is DatabaseProvider registered?
+  ```
+
+  — while it plainly was registered.
+
+  It was never only the queue. Nine providers run in `worker` — notifications, audit, media,
+  tenancy, scheduler among them — and a job exists to do work with models. `AuthProvider` and
+  `SessionProvider` are absent from `worker` correctly, having neither a request nor a
+  session; the ORM being absent was an oversight, dating to 1.0.2.
+
+  Found building the first cookbook app, whose first queued job could not run.
+
+- **Relation keys now accept the JS spelling, like every other identifier.** The convention is
+  camelCase in the application and snake_case in the database, converted on the way through —
+  and relation keys were the one place it did not happen. `@hasMany(() => Issue, { foreignKey:
+"projectId" })` type-checked and then emitted `no such column: issues.projectId`, with the
+  error naming a column rather than the relation that produced it.
+
+  `_relationSubquery()` builds its subquery with a plain `QueryBuilder`, and the `_column()`
+  hook that converts is an override on `ModelQueryBuilder`, so nothing was converting these.
+  The keys are now converted where they are qualified, which covers `withCount`, `withSum`,
+  `has`/`whereHas` and `withExists` for `hasMany`, `belongsTo`, `manyToMany` and the morph
+  relations. Both spellings resolve to the column, so apps already passing `project_id` are
+  unaffected.
+
+  Found building the first cookbook app, where a project list would not count its issues.
+
+## [1.7.0] — 2026-08-16
+
+### Fixed
+
+- **Migrations are now actually transactional.** The runner wrapped each `up()` in
+  `begin()` and the docblock promised all-or-nothing, but the wrapper governed nothing:
+  `Schema` resolved the _global_ connection, so the migration's DDL ran on a pooled
+  connection and committed independently of the transaction around it. On PostgreSQL a
+  migration that failed on its third statement left the first two behind, and the enclosing
+  `ROLLBACK` had nothing to undo.
+
+  Three changes close it. `Schema` resolves the enclosing transaction when there is one
+  (new `_getScopedDbConnection`), so DDL issued inside `DB.transaction()` joins it —
+  migrations included. The tracking-table insert moved _inside_ the transaction, because
+  recording after the commit leaves a window where the schema has moved and nothing says so,
+  and the next deploy re-runs the migration against a schema it already changed. And
+  rollback got the same treatment: a `down()` that fails part-way now undoes nothing rather
+  than leaving the schema and the tracking table disagreeing.
+
+  This was invisible to the test suite by construction — `new SQL(":memory:")` is a single
+  handle, so the "global" and transaction connections are the same object and DDL joined the
+  transaction by accident. The new tests use a fake that keeps them distinguishable.
+
+### Added
+
+- **`MigrationRunner.willRollBackOnFailure`** and `SqlDialect.supportsTransactionalDdl`.
+  MySQL and MariaDB implicitly commit on every DDL statement, so a transaction around a
+  migration there is a promise that cannot be kept — the runner no longer opens one, and
+  `bun zt migrate` warns before it starts rather than after something breaks. PostgreSQL
+  and SQLite report `true`.
+
+- **Two DevTools tabs the ORM already had the data for.** `ModelChanged`,
+  `TransactionCommitted` and `TransactionRolledBack` were on the framework event bus and went
+  nowhere: a request that wrote four rows and one that wrote none looked identical in the
+  panel, and a transaction that rolled back showed only as queries that appeared to succeed.
+
+  The observability bridge now declares a **Models** channel (grouped per model) and a
+  **Transactions** channel (marking a rollback as a warning, with its reason). Both are
+  declared as data, so DevTools ships no ORM-specific code — and both are skipped entirely
+  when DevTools is not installed, as every other bridge here is.
+
 ## [1.6.0] — 2026-08-15
 
 ### Fixed