@bakery-framework/orm 2.0.0-alpha.11 → 2.0.0-alpha.13

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bakery-framework/orm",
-  "version": "2.0.0-alpha.11",
+  "version": "2.0.0-alpha.13",
   "description": "Bakery database layer: adapters, query builder, schema sync and backup.",
   "keywords": [
     "bakery",
@@ -54,6 +54,6 @@
     "bun": ">=1.4.0"
   },
   "dependencies": {
-    "@bakery-framework/core": "^2.0.0-alpha.11"
+    "@bakery-framework/core": "^2.0.0-alpha.13"
   }
 }

package/src/adapters/base.ts

@@ -73,7 +73,33 @@ export namespace SQLAdapter {
   export interface TableDataOptions extends FilterSortOptions {
     page: number
     pageSize: number
+    /**
+     * A total the caller already has, so the `COUNT(*)` can be skipped.
+     *
+     * **The count is almost the whole cost of a page.** Measured on a
+     * 200,000-row SQLite table with a page size of 50, reading page 101:
+     *
+     *     count, no filter    11.7 ms      rows, no filter    0.4 ms
+     *     count, filtered     51.3 ms      rows, filtered     1.6 ms
+     *
+     * 97% of the work either way. The rows come off an index and stop at the
+     * page; the count has to visit every row that matches, and a filtered
+     * count visits them a second time after the rows query already did.
+     *
+     * Opt-in and caller-asserted, because it trades a guarantee for that.
+     * Passing a total says "I counted, with exactly these filters" - an
+     * adapter cannot check it, and a wrong one shows a wrong row count and a
+     * wrong page count. It never affects which rows come back, so the
+     * failure mode is a stale readout rather than wrong data. Paging through
+     * a table while another writer inserts is exactly when it goes stale, and
+     * exactly when re-counting on every page is least worth it.
+     *
+     * Ignored unless it is a non-negative finite number, so a bad value
+     * degrades to the count rather than to a negative page total.
+     */
+    knownTotal?: number
   }
+
   export interface NameRow {
     name: string
   }
@@ -202,6 +228,34 @@ export const DEFAULT_STREAM_CHUNK = 500
  * offset pagination has, and exactly what `seek()` exists to avoid. What it
  * does buy is the thing people reach for streaming to get: memory bounded by
  * the chunk instead of by the result.
+ *
+ * **What it costs, and why it is not one number.** The statement is
+ * re-executed per chunk, so the total is the chunk count times whatever one
+ * window costs — and what one window costs depends entirely on whether the
+ * ordering can be served from an index. If it cannot, every chunk sorts the
+ * whole result and throws away the offset, which is quadratic in the chunk
+ * count. Measured on 100,000 rows, a chunk size of 500, so 200 statements:
+ *
+ *     sqlite    ORDER BY the primary key     all 180 ms   iterate    593 ms     3x
+ *     sqlite    ORDER BY an unindexed column all 275 ms   iterate 35,687 ms   130x
+ *     postgres  ORDER BY the primary key     all  83 ms   iterate  1,590 ms    19x
+ *     postgres  ORDER BY an unindexed column all 126 ms   iterate 12,767 ms   101x
+ *
+ * Thirty-five seconds to walk what `all()` returns in 275 ms. The backlog
+ * recorded a flat "393x", which is the right neighbourhood for the unindexed
+ * case and says nothing about the case a caller can fix: **order by something
+ * indexed and the cost collapses by 40x.**
+ *
+ * The two dialects differ for different reasons. Postgres pays a network round
+ * trip per chunk, which is why its indexed case is 19x where SQLite's is 3x.
+ * SQLite pays nothing for the trip and everything for the sort, which is why
+ * its unindexed case is the worst of the four.
+ *
+ * So: reach for this when the result does not fit in memory, not when it is
+ * merely large. If it fits, `all()` is between 3 and 130 times faster. If it
+ * does not, index the column you order by, and prefer `seek()` where the shape
+ * allows it — that is keyset pagination and it has neither the cost nor the
+ * skipped-row hazard described above.
  */
 export function pagedIterate(
   all: SQLAdapter.Executor['all'],
@@ -303,6 +357,47 @@ export abstract class SQLAdapter {
     return DEFAULT_MAX_QUERY_PARAMS
   }
 
+  /**
+   * Whether a caller-supplied total can be used in place of a `COUNT(*)`.
+   *
+   * One rule in one place, because all three adapters answer it and a dialect
+   * that disagreed would be a bug rather than a capability. A static on the
+   * class rather than a function in the namespace: the namespace is declared
+   * above the class it merges with, so it can hold types and not values.
+   */
+  static usableTotal(value: unknown): value is number {
+    return typeof value === 'number' && Number.isFinite(value) && value >= 0
+  }
+
+  /**
+   * A cheap value that changes whenever the schema changes, or `null`.
+   *
+   * The capability is expressed by the return, not by a boolean beside it: a
+   * dialect that cannot answer this cheaply returns `null` and its callers
+   * fall back to asking the schema directly. That is the default here, so a
+   * new adapter is correct without implementing anything.
+   *
+   * **It must not move for ordinary DML.** A value that changed on every
+   * `INSERT` would still be *correct* as a cache key and useless as one,
+   * invalidating on the busiest thing a database does. SQLite's
+   * `PRAGMA schema_version` has exactly the right semantics, verified rather
+   * than assumed: it advances on `CREATE TABLE`, on `ALTER TABLE ... ADD
+   * COLUMN` and on `DROP TABLE`, and stays put across an `INSERT`.
+   *
+   * A method rather than one of the capability *getters* above because it
+   * costs a round trip. Those describe the dialect and are answered from
+   * nothing; this one asks the server.
+   *
+   * Postgres and MySQL return `null`. Neither exposes a single counter for
+   * this - Postgres has no schema-level equivalent of `schema_version`, and
+   * MySQL's `information_schema` would have to be aggregated, which is the
+   * expense being avoided. Adding one later is a per-adapter override and
+   * needs no change here or in any caller.
+   */
+  async schemaFingerprint(): Promise<string | null> {
+    return null
+  }
+
   constructor(
     public readonly driver: SQLAdapter.Driver,
     public readonly filename?: string,
@@ -1243,6 +1338,19 @@ export class DatabaseStatement {
   values(...params: any[]) {
     return this.connection.execute.values(this.sql, params)
   }
+  /**
+   * Walk the result a chunk at a time, holding only the chunk.
+   *
+   * **Not a cursor, and not cheap.** Bun cannot stream, so this pages: the
+   * statement becomes a derived table and is re-executed once per 500 rows.
+   * On 100,000 rows that is 200 statements, and the total depends on whether
+   * the ordering is indexed — 3x `all()` on SQLite ordered by a primary key,
+   * **130x** ordered by a column with no index (35.7 seconds against 275 ms).
+   * The full table and the reasoning are on {@link pagedIterate}.
+   *
+   * Use it when the result does not fit in memory. When it does, `all()` is
+   * faster by between 3 and 130 times.
+   */
   iterate(...params: any[]) {
     return this.connection.execute.iterate(this.sql, params)
   }

package/src/adapters/mysql.ts

@@ -332,10 +332,15 @@ export class MySQLAdapter extends SQLAdapter {
       new Set(cols.map(c => c.name)),
     )
     const tName = this.quote(tableName)
-    const countRes = (await this.query(
-      `SELECT COUNT(*) as count FROM ${tName}${whereSql}`,
-    ).get(...whereParams)) as SQLAdapter.CountRow
-    const totalRows = countRes?.count || 0
+    // See `TableDataOptions.knownTotal`: the count is almost the whole cost
+    // of a page, and a caller that has already counted can say so.
+    const reuse = SQLAdapter.usableTotal(options.knownTotal)
+    const countRes = reuse
+      ? null
+      : ((await this.query(
+          `SELECT COUNT(*) as count FROM ${tName}${whereSql}`,
+        ).get(...whereParams)) as SQLAdapter.CountRow)
+    const totalRows = reuse ? options.knownTotal! : countRes?.count || 0
     const rows = await this.query(
       `SELECT * FROM ${tName}${whereSql}${orderSql} LIMIT ? OFFSET ?`,
     ).all(

package/src/adapters/pgsql.ts

@@ -57,7 +57,11 @@ export class PGAdapter extends SQLAdapter {
 
   private static handleSpecial(
     char: string,
-    nextChar: string | undefined,
+    // Underscored because it is deliberately unread: the branch that would
+    // have used it is the backslash branch, and the comment below is why
+    // there is not one. Kept in the signature so the shape matches
+    // `handleSpecial` in the other two adapters.
+    _nextChar: string | undefined,
     state: PGSQLParserState,
   ): string | null {
     // No backslash branch, deliberately. Postgres with
@@ -333,10 +337,15 @@ export class PGAdapter extends SQLAdapter {
       new Set(cols.map(c => c.name)),
     )
     const tName = this.quote(tableName)
-    const countRes = (await this.query(
-      `SELECT COUNT(*) as count FROM ${tName}${whereSql}`,
-    ).get(...whereParams)) as SQLAdapter.CountRow
-    const totalRows = countRes?.count || 0
+    // See `TableDataOptions.knownTotal`: the count is almost the whole cost
+    // of a page, and a caller that has already counted can say so.
+    const reuse = SQLAdapter.usableTotal(options.knownTotal)
+    const countRes = reuse
+      ? null
+      : ((await this.query(
+          `SELECT COUNT(*) as count FROM ${tName}${whereSql}`,
+        ).get(...whereParams)) as SQLAdapter.CountRow)
+    const totalRows = reuse ? options.knownTotal! : countRes?.count || 0
     const rows = (await this.query(
       `SELECT ctid::text AS rowid, * FROM ${tName}` +
         `${whereSql}${orderSql} LIMIT ? OFFSET ?`,

package/src/adapters/sqlite.ts

@@ -1,10 +1,20 @@
 import path from 'node:path'
 import { Bakery } from '@bakery-framework/core/core/bakery'
+import { Logger, messageLogger } from '@bakery-framework/core/logger'
 import { Case, Try } from '@bakery-framework/core/utils'
 import { SQL } from 'bun'
 import type * as SyncTypes from '../sync/types'
 import { createExecutor, SQLAdapter } from './base'
 
+// Convention 4: logging is data, declared in a table rather than formatted at
+// the call site.
+const MESSAGES = messageLogger(new Logger('database'), {
+  JOURNAL_WAL_REFUSED:
+    'W SQLite refused WAL for %y{file}%* (answered %y{answer}%*) — running the %y{mode}%* journal instead. Expected on a network path; on a local disk it costs every write.',
+  PRAGMA_FAILED:
+    'W A SQLite performance pragma was rejected: %r{error}%*. The database works; it is not tuned.',
+} as const)
+
 export class SQLiteAdapter extends SQLAdapter {
   // SQLite's standard identifier quote. The base class defaults to MySQL's
   // backtick, which SQLite only tolerates as a compatibility extension.
@@ -12,6 +22,20 @@ export class SQLiteAdapter extends SQLAdapter {
 
   protected readonly sql: SQL
 
+  /**
+   * Resolves when the performance pragmas have finished, or failed loudly.
+   *
+   * They are deliberately not awaited by every query the way `ready` is —
+   * tuning is not correctness, and making the first statement of every process
+   * wait on six round trips to gain nothing is the wrong trade. But `close()`
+   * has to wait, because a handle closed underneath an in-flight pragma
+   * rejects with `Connection closed`, and that is indistinguishable at the
+   * catch from a filesystem genuinely refusing one. A short-lived adapter — a
+   * test, a one-shot script — would otherwise warn on every close about a
+   * failure that never happened.
+   */
+  protected readonly tuned: Promise<unknown> = Promise.resolve()
+
   /**
    * Resolves once `foreign_keys` is on, and every query awaits it.
    *
@@ -151,18 +175,105 @@ export class SQLiteAdapter extends SQLAdapter {
 
     if (ownsConnection && filename !== ':memory:') {
       const cacheSize = import.meta.env.THREAD_WORKER ? -1000 : -10000
-      const journalMode = process.platform === 'win32' ? 'DELETE' : 'WAL'
-      this.sql
-        .unsafe(`PRAGMA journal_mode = ${journalMode};`)
+      this.tuned = this.sql
+        .unsafe('PRAGMA journal_mode = WAL;')
+        .then((rows: unknown) => this.confirmWAL(rows, filename))
         .then(() => this.sql.unsafe('PRAGMA synchronous = NORMAL;'))
         .then(() => this.sql.unsafe('PRAGMA temp_store = memory;'))
         .then(() => this.sql.unsafe(`PRAGMA cache_size = ${cacheSize};`))
         .then(() => this.sql.unsafe('PRAGMA busy_timeout = 5000;'))
         .then(() => this.sql.unsafe('PRAGMA mmap_size = 0;'))
-        .catch(() => {})
+        // Not `catch(() => {})`. Every performance pragma failing silently is
+        // how a database ends up running at a fraction of its speed with
+        // nothing anywhere saying so, and convention 3 bans the bare form for
+        // exactly this. These are tuning, not correctness — `foreign_keys`
+        // above is awaited and is allowed to reject — so a failure is a
+        // warning rather than a throw.
+        .catch((error: Error) => {
+          MESSAGES.PRAGMA_FAILED({ error: error.message })
+        })
     }
   }
 
+  /**
+   * Waits for the pragma chain before closing the handle. See `tuned`.
+   */
+  override async close(): Promise<void> {
+    await Try.catch(this.tuned)
+    await super.close()
+  }
+
+  /**
+   * **WAL first, DELETE only where WAL is actually refused.**
+   *
+   * The journal mode used to be `platform === 'win32' ? 'DELETE' : 'WAL'`, a
+   * rule with no recorded reason. The hypothesis behind it was that a Windows
+   * network path cannot host WAL, which is true — WAL needs a shared `-shm`
+   * mapping that SMB and WebDAV do not provide — but the rule applied to every
+   * Windows install, local disks included, where WAL works.
+   *
+   * Measured on this machine, four interleaved rounds against a CPU-bound
+   * control that stayed flat at 29-34 ms:
+   *
+   *     single autocommit write    DELETE 3629 us    WAL 36 us      100x
+   *     100-row transaction        DELETE 3.91 ms    WAL 0.13 ms     29x
+   *
+   * An attempt and a check replaces the rule, which is what makes it safe to
+   * change without knowing why it was there. SQLite refuses WAL in two
+   * observable ways and both are handled: it returns the *unchanged* mode in
+   * the pragma's own result row (an in-memory database answers `memory`), or
+   * it throws. Both shapes were reproduced before this was written, so the
+   * fallback rests on a measurement rather than on the documentation.
+   *
+   * The same logic runs on the cache database in
+   * `@bakery-framework/core/cache/shared-db`. It is deliberately not shared:
+   * that site is synchronous `bun:sqlite` and this one is an async
+   * `Bun.SQL`, so the control flow has nothing in common and only the
+   * predicate would move — at the cost of a new published export subpath on a
+   * surface that was closed on purpose before 2.0.0.
+   */
+  private async confirmWAL(rows: unknown, filename: string): Promise<void> {
+    const first = Array.isArray(rows) ? rows[0] : undefined
+    const answer = String(
+      (first as { journal_mode?: unknown } | undefined)?.journal_mode ?? '',
+    )
+    if (answer.toLowerCase() === 'wal') return
+
+    const fell = await this.sql.unsafe('PRAGMA journal_mode = DELETE;')
+    const mode = Array.isArray(fell)
+      ? String((fell[0] as { journal_mode?: unknown })?.journal_mode ?? 'unknown')
+      : 'unknown'
+    MESSAGES.JOURNAL_WAL_REFUSED({
+      file: filename,
+      answer: answer || '(no row)',
+      mode,
+    })
+  }
+
+  /**
+   * `PRAGMA schema_version`, which is a counter SQLite bumps on every schema
+   * change and leaves alone for every row change.
+   *
+   * Measured on a 50-table database: the full introspection the explorer runs
+   * per write is **250 statements and 8.28 ms**, and this is **10.4 us** - 795x.
+   * The semantics were checked rather than taken from the documentation: the
+   * counter advances on `CREATE TABLE`, on `ALTER TABLE ... ADD COLUMN` and on
+   * `DROP TABLE`, and does not move for an `INSERT`.
+   *
+   * Prefixed with the driver and the file so two different SQLite databases
+   * cannot collide on the same small integer. A fresh database starts near
+   * zero, so "version 3" is a value many of them hold at once.
+   */
+  override async schemaFingerprint(): Promise<string | null> {
+    const row = (await this.query('PRAGMA schema_version').get()) as
+      | { schema_version?: number }
+      | null
+      | undefined
+    const version = row?.schema_version
+    if (typeof version !== 'number') return null
+    return `sqlite:${this.filename ?? ''}:${version}`
+  }
+
   private static resolveFilename(rawValue?: string | null): string {
     const envVal = process.env.DATABASE_URL || process.env.SQLITE_PATH
     // `Bakery.dataDir`, not a literal: the default database file has to follow
@@ -351,17 +462,23 @@ export class SQLiteAdapter extends SQLAdapter {
 
     const { page, pageSize } = options
 
+    // See `TableDataOptions.knownTotal`: the count is 97% of a page's cost,
+    // and a caller that has already counted can say so.
+    const reuse = SQLAdapter.usableTotal(options.knownTotal)
+
     const [countRes, rows] = (await Promise.all([
-      this.query(`SELECT COUNT(*) as count FROM ${tname}${whereSql}`).get(
-        ...whereParams,
-      ),
+      reuse
+        ? Promise.resolve(null)
+        : this.query(`SELECT COUNT(*) as count FROM ${tname}${whereSql}`).get(
+            ...whereParams,
+          ),
       this.query(
         `SELECT rowid AS rowid, * FROM ${tname}` +
           `${whereSql}${orderSql} LIMIT ? OFFSET ?`,
       ).all(...whereParams, pageSize, (page - 1) * pageSize),
-    ])) as [SQLAdapter.CountRow, any[]]
+    ])) as [SQLAdapter.CountRow | null, any[]]
 
-    const totalRows = countRes?.count || 0
+    const totalRows = reuse ? options.knownTotal! : countRes?.count || 0
     return {
       rows,
       totalRows,
@@ -469,9 +586,13 @@ export class SQLiteAdapter extends SQLAdapter {
       const tName = Case.camel(table.name)
       dbConstraints[tName] = {} as SyncTypes.TableConstraints
 
+      // Bound, not interpolated — the same conversion `hasCol` above
+      // records. This one survived it: `getConstraints` runs over every table
+      // the database reports, so a name carrying an apostrophe closed the
+      // literal and the rest of the statement went with it.
       const cols = (await this.query(
-        `PRAGMA table_info('${table.name}')`,
-      ).all()) as any[]
+        'SELECT * FROM pragma_table_info(?)',
+      ).all(table.name)) as any[]
 
       if (table.type === 'view') {
         const match = table.sql.match(/AS\s+(.*)/is)
@@ -509,8 +630,12 @@ export class SQLiteAdapter extends SQLAdapter {
     return Object.fromEntries(
       await Promise.all(
         indexes.map(async idx => {
+          // Bound for the same reason as `getConstraints` above: an index
+          // name comes from `sqlite_master`, not from this codebase.
           const raw = (
-            (await this.query(`PRAGMA index_info('${idx.name}')`).all()) as any[]
+            (await this.query('SELECT * FROM pragma_index_info(?)').all(
+              idx.name,
+            )) as any[]
           ).map(c => String(c.name))
           return [
             Case.camel(idx.name),

package/src/orm/mutation.ts

@@ -7,7 +7,7 @@ import type {
   AppDBOptionals as DBOptionals,
   AppDBSchema as DBSchema,
 } from '../schema-registry'
-import { evalOperands, qId } from '../schema-util'
+import { evalOperands, nullComparison, qId } from '../schema-util'
 import { DB } from './query'
 
 export namespace Mutation {
@@ -475,8 +475,12 @@ export namespace Mutation {
         if (c.operator === '') {
           parts.push(i === 0 ? left : `${c.connector} ${left}`)
         } else {
-          const right = evalOperands(c.right, params, c.isRightColumn)
-          const clauseStr = `${left} ${c.operator} ${right}`
+          // `nullComparison` before `evalOperands`, and the order is the point:
+          // a null that becomes `IS NULL` must not also bind a parameter.
+          const nullOp = nullComparison(c.operator, c.right, c.isRightColumn)
+          const clauseStr = nullOp
+            ? `${left} ${nullOp}`
+            : `${left} ${c.operator} ${evalOperands(c.right, params, c.isRightColumn)}`
           parts.push(i === 0 ? clauseStr : `${c.connector} ${clauseStr}`)
         }
       }
@@ -630,8 +634,12 @@ export namespace Mutation {
         if (c.operator === '') {
           parts.push(i === 0 ? left : `${c.connector} ${left}`)
         } else {
-          const right = evalOperands(c.right, params, c.isRightColumn)
-          const clauseStr = `${left} ${c.operator} ${right}`
+          // `nullComparison` before `evalOperands`, and the order is the point:
+          // a null that becomes `IS NULL` must not also bind a parameter.
+          const nullOp = nullComparison(c.operator, c.right, c.isRightColumn)
+          const clauseStr = nullOp
+            ? `${left} ${nullOp}`
+            : `${left} ${c.operator} ${evalOperands(c.right, params, c.isRightColumn)}`
           parts.push(i === 0 ? clauseStr : `${c.connector} ${clauseStr}`)
         }
       }

package/src/orm/query.ts

@@ -2,18 +2,7 @@ import { Case } from '@bakery-framework/core/utils'
 import { throws } from '@bakery-framework/core/utils/common'
 import { getActiveDb, txStorage } from '../connection'
 import type { AppDBSchema as DBSchema } from '../schema-registry'
-import {
-  evalOperands,
-  isSafeIdentifier,
-  qId,
-  qRaw,
-  SQL_FUNCTIONS,
-  col as schemaCol,
-  ColumnRef as schemaColumnRef,
-  OperatorRef as schemaOperatorRef,
-  SQLFunctionRef as schemaSQLFunctionRef,
-  WindowRef as schemaWindowRef,
-} from '../schema-util'
+import { ColumnRef as schemaColumnRef, OperatorRef as schemaOperatorRef, SQLFunctionRef as schemaSQLFunctionRef, SQL_FUNCTIONS, WindowRef as schemaWindowRef, col as schemaCol, evalOperands, isSafeIdentifier, nullComparison, qId, qRaw } from '../schema-util'
 import { Mutation } from './mutation'
 
 export namespace DB {
@@ -501,6 +490,27 @@ export namespace DB {
       ])
     }
 
+    /**
+     * Walk the result a chunk at a time, holding only the chunk.
+     *
+     * **The name promises a cursor and the implementation is paging**, because
+     * Bun cannot stream: the statement becomes a derived table and is
+     * re-executed once per 500 rows. Two consequences, and the second is the
+     * one that surprises people.
+     *
+     * Chunk boundaries are only stable under a total order, so a row inserted
+     * or deleted mid-walk can be seen twice or missed. `seek()` is keyset
+     * pagination and has neither problem.
+     *
+     * And it is slow in proportion to how badly the ordering indexes.
+     * Measured on 100,000 rows: 3x `all()` on SQLite ordered by a primary key,
+     * **130x** ordered by a column with no index — 35.7 seconds against
+     * 275 ms. Postgres pays a round trip per chunk instead and lands at 19x
+     * and 101x. The table is on `pagedIterate` in `adapters/base.ts`.
+     *
+     * Worth it when the result does not fit in memory. Not worth it merely
+     * because the result is large.
+     */
     async *iterable(): AsyncIterable<P> {
       const { sql, params } = this.parse()
       for await (const row of getActiveDb()
@@ -1072,16 +1082,9 @@ export namespace DB {
     if (op === 'IS NULL' || op === 'IS NOT NULL') {
       return `${left} ${op}`
     }
-    // A bound NULL can never satisfy `=` or `<>` — three-valued logic makes
-    // both comparisons UNKNOWN for every row, so `where(col, null)` silently
-    // matched nothing while cheerfully reporting success. The caller who
-    // passes an explicit null means the SQL spelling of it. Only literal
-    // values: a column reference on the right is a different comparison and
-    // is left alone.
-    if (rightArg === null && !isRightColumn) {
-      if (op === '=') return `${left} IS NULL`
-      if (op === '!=' || op === '<>') return `${left} IS NOT NULL`
-    }
+    // One rule, three callers — see `nullComparison`.
+    const nullOp = nullComparison(op, rightArg, isRightColumn)
+    if (nullOp) return `${left} ${nullOp}`
     if (op === 'BETWEEN' && Array.isArray(rightArg)) {
       const min = evalOperands(rightArg[0], params, false)
       const max = evalOperands(rightArg[1], params, false)

package/src/schema-util.ts

@@ -465,3 +465,35 @@ export function old(
     _transform: transform,
   })
 }
+
+/**
+ * The SQL spelling of a comparison against an explicit `null`, or `null` when
+ * the comparison is an ordinary one.
+ *
+ * A bound NULL can never satisfy `=` or `<>`: three-valued logic makes both
+ * UNKNOWN for every row, so `where(col, null)` matched nothing while reporting
+ * success. On a `SELECT` that is an empty result; on a `DELETE` or an
+ * `UPDATE` it is a write that silently does nothing and answers zero changes,
+ * which a caller cannot tell from a genuine conflict.
+ *
+ * **This lives here, not in a `WHERE` builder, because there are three of
+ * them.** `formatClause` in `orm/query.ts` and the two `evalWhere` copies in
+ * `orm/mutation.ts` each compile a clause, and the copies have now diverged
+ * twice: once over the one-argument `where(DB.raw\`…\`)` form, which the
+ * comment in `DeleteExecutable.evalWhere` records, and once over this rule,
+ * which reached the builder and neither mutation path. Both were silent. One
+ * function three callers share cannot drift a third time.
+ *
+ * A column reference on the right is a different comparison and is left alone.
+ */
+export function nullComparison(
+  operator: string,
+  right: unknown,
+  isRightColumn?: boolean,
+): string | null {
+  if (right !== null || isRightColumn) return null
+  const op = operator.toUpperCase()
+  if (op === '=') return 'IS NULL'
+  if (op === '!=' || op === '<>') return 'IS NOT NULL'
+  return null
+}