@zerotal/orm 1.7.0 → 1.7.2

package/CHANGELOG.md

@@ -6,6 +6,58 @@ follows the Zerotal monorepo's unified versioning.
 
 **Maturity: `stable`**
 
+## [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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zerotal/orm",
-  "version": "1.7.0",
+  "version": "1.7.2",
   "license": "MIT",
   "maturity": "stable",
   "private": false,
@@ -31,8 +31,8 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@zerotal/core": "1.7.0",
-    "@zerotal/validator": "1.7.0"
+    "@zerotal/core": "1.7.2",
+    "@zerotal/validator": "1.7.2"
   },
   "devDependencies": {
     "typescript": "^5.8.0"

package/src/commands/_runSeeders.ts

@@ -1,4 +1,5 @@
 import type { Seeder } from "../seeding/Seeder.ts";
+import { DB, _getDbConnectionOverride } from "../db/DB.ts";
 
 /**
  * What running the app's seeders came to.
@@ -27,6 +28,30 @@ export type SeedOutcome =
  *
  * @internal
  */
+/**
+ * Run `body` inside a transaction when there is a database to have one on.
+ *
+ * A seeder is not obliged to touch the database — it may write fixtures to disk,
+ * prime a cache, or call an API — and an app that has not bound a connection
+ * should not fail to seed because of a transaction it never needed. So the
+ * wrapper is conditional: with a connection, the whole seed is atomic; without,
+ * `body` runs exactly as it used to.
+ */
+async function _inTransaction(body: () => Promise<void>): Promise<void> {
+  let connected = _getDbConnectionOverride() !== null;
+  if (!connected) {
+    // No override — ask the container, which throws when nothing is bound.
+    try {
+      const { _getConnection } = await import("../db/DB.ts");
+      connected = _getConnection() !== undefined;
+    } catch {
+      connected = false;
+    }
+  }
+  if (!connected) return body();
+  await DB.transaction(body);
+}
+
 export async function runSeeders(cwd: string = process.cwd()): Promise<SeedOutcome> {
   const seederPath = `${cwd}/database/seeders/DatabaseSeeder.ts`;
 
@@ -42,7 +67,9 @@ export async function runSeeders(cwd: string = process.cwd()): Promise<SeedOutco
       if (!seed) {
         return { status: "invalid", message: "Seeder index must export a default async function." };
       }
-      await seed();
+      await _inTransaction(async () => {
+        await seed();
+      });
       return { status: "seeded" };
     } catch (error) {
       return { status: "failed", message: error instanceof Error ? error.message : String(error) };
@@ -63,7 +90,20 @@ export async function runSeeders(cwd: string = process.cwd()): Promise<SeedOutco
       };
     }
 
-    await new SeederClass().run();
+    // One transaction around the whole seed.
+    //
+    // `Seeder.call()` has always wrapped *composed* seeders, so a DatabaseSeeder
+    // that delegates was atomic and one that does its work inline — which is
+    // most of them — was not. A failure halfway left its rows committed, 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.
+    //
+    // Nesting is safe: `DB.transaction` opens a SAVEPOINT when one is already
+    // open, so an inner `call()` still rolls back independently.
+    await _inTransaction(async () => {
+      await new SeederClass().run();
+    });
     return { status: "seeded" };
   } catch (error) {
     return { status: "failed", message: error instanceof Error ? error.message : String(error) };

package/src/model/ModelQueryBuilder.ts

@@ -813,26 +813,36 @@ export class ModelQueryBuilder<M extends BaseModel> extends QueryBuilder {
       );
     }
 
+    // Relation keys carry the *JS* spelling — `@hasMany(Issue, { foreignKey:
+    // "projectId" })` — because that is the convention everywhere else: camelCase
+    // in the application, snake_case in the database, converted on the way
+    // through. `_column()` does that conversion, but it is an override on
+    // *this* class and the subquery below is a plain `QueryBuilder`, so nothing
+    // was converting these. The result was a correct-looking decorator emitting
+    // `no such column: issues.projectId`, with the error naming a column rather
+    // than the relation that produced it.
+    const col = (table: string, key: string): string => `${table}.${_toSnakeColumn(key)}`;
+
     if (meta.type === "manyToMany") {
       const relTable = Related.table;
       sub = new QueryBuilder(meta.pivotTable!, this._sql)
         .join(
           relTable,
-          `${relTable}.${Related.primaryKey}`,
+          col(relTable, Related.primaryKey),
           "=",
-          `${meta.pivotTable}.${meta.pivotRelatedKey}`,
+          col(meta.pivotTable!, meta.pivotRelatedKey!),
         )
-        .whereColumn(`${meta.pivotTable}.${meta.pivotForeignKey}`, `${main}.${meta.localKey}`);
+        .whereColumn(col(meta.pivotTable!, meta.pivotForeignKey!), col(main, meta.localKey!));
       if (Related.softDeletes) sub.whereNull(`${relTable}.deleted_at`);
     } else {
       const relTable = Related.table;
       sub = new QueryBuilder(relTable, this._sql);
       if (meta.type === "belongsTo") {
-        sub.whereColumn(`${relTable}.${meta.localKey}`, `${main}.${meta.foreignKey}`);
+        sub.whereColumn(col(relTable, meta.localKey!), col(main, meta.foreignKey!));
       } else {
-        sub.whereColumn(`${relTable}.${meta.foreignKey}`, `${main}.${meta.localKey}`);
+        sub.whereColumn(col(relTable, meta.foreignKey!), col(main, meta.localKey!));
         if (meta.type === "morphMany" || meta.type === "morphOne") {
-          sub.where(`${relTable}.${meta.morphTypeColumn}`, this._ModelClass.name);
+          sub.where(col(relTable, meta.morphTypeColumn!), this._ModelClass.name);
         }
       }
       if (Related.softDeletes) sub.whereNull(`${relTable}.deleted_at`);

package/src/provider/DatabaseProvider.ts

@@ -51,8 +51,22 @@ declare module "@zerotal/core" {
  */
 export class DatabaseProvider extends ServiceProvider {
   static override provides = ["db"] as const;
+  /**
+   * Every mode, `worker` included.
+   *
+   * `worker` was missing until 1.7.1, which meant `bun zt queue:work` could not
+   * boot at all: the queue's own default driver is `sqlite`, `QueueProvider`
+   * does run in `worker`, and it asks for a connection this provider had not
+   * made — so the worker died on startup with "No database connection. Is
+   * DatabaseProvider registered?" while it plainly was.
+   *
+   * 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. A worker without a database is a worker that cannot do the
+   * thing workers are for.
+   */
   // Use an explicit mutable array type to satisfy ServiceProvider's static property constraint.
-  static override environments: AppEnvironment[] = ["web", "console", "test", "repl"];
+  static override environments: AppEnvironment[] = ["web", "console", "worker", "test", "repl"];
 
   private _disposeObservability: (() => void) | undefined = undefined;