Classes

Default: every Drizzle adapter except D1 can wrap writeBatch in a native transaction. D1 overrides this to false (only supports db.batch(), which writeBatch maps to natively).

Runs a raw query and returns its result rows, normalized from the driver's shape into a plain array. See OrmDatabase.executeRows.

Returns the largest chunk size that keeps a single statement's bound parameters under this.maxSQLVariables, with a 10% headroom for other parameters in the same query. Pass 1 for a list of scalar IDs.

Builds a time-bucketed histogram with conditional counts using direct aggregation.

• Uses GROUP BY on time buckets directly from table data.
• Much faster than CTE + JOIN approach for large datasets.
• Returns OrmTimeSeriesResult format.

Interactive read-write transaction. Throws on adapters where supportsInteractiveTransactions === false (D1). For portable atomic writes, use writeBatch.

Native upsert — single atomic statement using the dialect's conflict resolution syntax (ON CONFLICT DO UPDATE on SQLite/Postgres, ON DUPLICATE KEY UPDATE on MySQL). The dialect-specific work lives in upsertBatch; this is the single-row convenience wrapper.

conditions holds the entity's identifying fields (typically the primary key). It's not a where clause — there's no read involved.

better-sqlite3's .transaction() is synchronous and (since v12) throws if the callback returns a promise, so the inherited async writeBatch (DrizzleAdapterBase) hits that guard. Run the batch synchronously inside the transaction instead: drizzle's better-sqlite3 session runs the callback synchronously and returns its value directly. This is also strictly MORE correct than the async path was here — an async callback resolved to a promise that committed at the first await, so the batch ran auto-committed outside any transaction (silently non-atomic). Production drivers are unaffected: PlanetScale keeps the async base path (its session awaits), and D1 / Durable Objects override writeBatch entirely.

Default: every Drizzle adapter except D1 can wrap writeBatch in a native transaction. D1 overrides this to false (only supports db.batch(), which writeBatch maps to natively).

Runs a raw query and returns its result rows, normalized from the driver's shape into a plain array. See OrmDatabase.executeRows.

Returns the largest chunk size that keeps a single statement's bound parameters under this.maxSQLVariables, with a 10% headroom for other parameters in the same query. Pass 1 for a list of scalar IDs.

Builds a time-bucketed histogram with conditional counts using direct aggregation.

• Uses GROUP BY on time buckets directly from table data.
• Much faster than CTE + JOIN approach for large datasets.
• Returns OrmTimeSeriesResult format.

Interactive read-write transaction. Throws on adapters where supportsInteractiveTransactions === false (D1). For portable atomic writes, use writeBatch.

Native upsert — single atomic statement using the dialect's conflict resolution syntax (ON CONFLICT DO UPDATE on SQLite/Postgres, ON DUPLICATE KEY UPDATE on MySQL). The dialect-specific work lives in upsertBatch; this is the single-row convenience wrapper.

conditions holds the entity's identifying fields (typically the primary key). It's not a where clause — there's no read involved.

D1 has no interactive transactions — use db.batch([...]) for atomic batched writes instead. Builds Drizzle query handles (unawaited), passes them to D1's batch API, then maps results back to the input operation order. No-op operations (e.g. an update with an empty where clause) are returned as zero-affected without occupying a batch slot.

Default: every Drizzle adapter except D1 can wrap writeBatch in a native transaction. D1 overrides this to false (only supports db.batch(), which writeBatch maps to natively).

Dialect-specific upsert query construction. SQLite/Postgres use ON CONFLICT DO UPDATE, MySQL uses ON DUPLICATE KEY UPDATE. Subclasses provide the actual builder.

Convert driver-specific delete result to ORM delete result.

Convert driver-specific insert result to ORM insert result.

Convert driver-specific update result(s) to ORM update result.

Convert driver-specific upsert result(s) to ORM insert result.

Runs a raw query and returns its result rows, normalized from the driver's shape into a plain array. See OrmDatabase.executeRows.

Returns the largest chunk size that keeps a single statement's bound parameters under this.maxSQLVariables, with a 10% headroom for other parameters in the same query. Pass 1 for a list of scalar IDs.

Interactive read-write transaction. Throws on adapters where supportsInteractiveTransactions === false (D1). For portable atomic writes, use writeBatch.

Native upsert — single atomic statement using the dialect's conflict resolution syntax (ON CONFLICT DO UPDATE on SQLite/Postgres, ON DUPLICATE KEY UPDATE on MySQL). The dialect-specific work lives in upsertBatch; this is the single-row convenience wrapper.

conditions holds the entity's identifying fields (typically the primary key). It's not a where clause — there's no read involved.

Atomic batch of write operations. Default impl wraps the operations in a Drizzle transaction; D1 overrides to use db.batch([...]) since it has no transaction support. Either way, all operations commit together or none do.

Default: every Drizzle adapter except D1 can wrap writeBatch in a native transaction. D1 overrides this to false (only supports db.batch(), which writeBatch maps to natively).

Runs a raw query and returns its result rows, normalized from the driver's shape into a plain array. See OrmDatabase.executeRows.

Returns the largest chunk size that keeps a single statement's bound parameters under this.maxSQLVariables, with a 10% headroom for other parameters in the same query. Pass 1 for a list of scalar IDs.

Builds a time-bucketed histogram with conditional counts using direct aggregation.

• Uses GROUP BY on time buckets directly from table data.
• Much faster than CTE + JOIN approach for large datasets.
• Returns OrmTimeSeriesResult format.

Interactive read-write transaction. Throws on adapters where supportsInteractiveTransactions === false (D1). For portable atomic writes, use writeBatch.

Native upsert — single atomic statement using the dialect's conflict resolution syntax (ON CONFLICT DO UPDATE on SQLite/Postgres, ON DUPLICATE KEY UPDATE on MySQL). The dialect-specific work lives in upsertBatch; this is the single-row convenience wrapper.

conditions holds the entity's identifying fields (typically the primary key). It's not a where clause — there's no read involved.

The inherited writeBatch wraps the operations in Drizzle's db.transaction, which the durable-sqlite driver implements via workerd's SYNCHRONOUS transactionSync — an async callback escapes it at its first await, the empty transaction commits immediately, and every batched statement then runs auto-committed outside any transaction (op N failing leaves ops 1..N-1 applied). Wrap the batch in the async-safe storage.transaction instead — the same rationale as the transaction() override above: DO storage is one SQLite engine, so SQL issued through this.db inside it is atomic.

Default: every Drizzle adapter except D1 can wrap writeBatch in a native transaction. D1 overrides this to false (only supports db.batch(), which writeBatch maps to natively).

Runs a raw query and returns its result rows, normalized from the driver's shape into a plain array. See OrmDatabase.executeRows.

Returns the largest chunk size that keeps a single statement's bound parameters under this.maxSQLVariables, with a 10% headroom for other parameters in the same query. Pass 1 for a list of scalar IDs.

Builds a time-bucketed histogram with optional conditional counts, using MySQL date functions. Mirrors the SQLite adapter's behavior with DATE_FORMAT/FROM_UNIXTIME in place of strftime. Supports COUNT(DISTINCT <column>) per bucket via options.distinctColumn.

Interactive read-write transaction. Throws on adapters where supportsInteractiveTransactions === false (D1). For portable atomic writes, use writeBatch.

Native upsert — single atomic statement using the dialect's conflict resolution syntax (ON CONFLICT DO UPDATE on SQLite/Postgres, ON DUPLICATE KEY UPDATE on MySQL). The dialect-specific work lives in upsertBatch; this is the single-row convenience wrapper.

conditions holds the entity's identifying fields (typically the primary key). It's not a where clause — there's no read involved.

Atomic batch of write operations. Default impl wraps the operations in a Drizzle transaction; D1 overrides to use db.batch([...]) since it has no transaction support. Either way, all operations commit together or none do.

Create a new instance of the entity with the given data.

Resolves the OrmDatabase for an injection site.

Database selection precedence:

1. an explicit token (a DatabaseBinding/key passed to the decorator) — always wins;
2. otherwise the requestingClass's declared module membership (@Injectable(SomeModuleKey), @WorkerScoped(SomeModuleKey), …) — resolved through the module graph, so the worker's database registration modifier applies;
3. otherwise the default database — a uniform contract in every worker. Registration never routes injections; boot validation rejects a non-default-database module's class with token-less injections that forgot to declare (see BaseConfiguration.getDatabaseNameForClass).

Whether any write operations have been queued.

Executes the queued operations as one atomic writeBatch against the provided database, then runs the onSuccess callbacks in registration order. A batch can only be committed once.

Queue a delete by arbitrary conditions (the batch counterpart of OrmDatabase.delete(target, conditions)). No entity lifecycle hooks run because no entity instances are involved.

Queue a raw write statement (built with the drizzle sql template) to run inside the same atomic batch — the escape hatch for bulk updates the entity API can't express (computed SET clauses, conditional shifts, increments). No entity lifecycle hooks run for it.

Registers a callback to run after the batch commits successfully.

Applies value transformers when preparing data for database This should be called before insert/update operations

Hydrates an array of raw objects into entity instances

Hydrates a single raw object into an entity instance

Whether this row has been updated since it was created.

updatedAt is initialized to the same instant as createdAt on insert, then bumped on every update — so the row has never been updated exactly when updatedAt === createdAt. (This replaces the old "updatedAt is null" sentinel, which couldn't work on backends where the column is NOT NULL.)

Create a new instance of the entity with the given data.

Opt in to client-supplied column filters for a fixed set of columns.

Fail closed: until a resolver calls this, any client filters are REJECTED with an ArgumentValidationError — a query can never be filter-injected on a column the server didn't explicitly expose, and a filter the server won't honor is never silently dropped (which would over-return rows the client asked to exclude). Once an allowlist is set, a client filter naming a column outside it throws rather than being silently applied or silently dropped.

This is the deliberate, narrow seam for exposing client-driven filtering. Server-mandated conditions still go through scopeWhere and always win over client filters.

On an input declared with @PaginationInputFor, this may only NARROW the declared set — the declaration is the outer bound of what the type exposes, and widening past it here would silently contradict the schema.

Opt in to client-supplied ordering for a fixed set of columns. Same contract as allowFilterColumns: until set (directly or via a @PaginationInputFor declaration), client orderBy is REJECTED — an unvetted sort column is an unindexed-sort surface, so the columns listed here are a statement that the query was planned for them. On a declared input, this may only narrow the declared set.

Adds server-mandated scope conditions to the query.

Scope conditions are AND'd with the client-supplied filters and ALWAYS win on key collision — a client filter can never override or drop a scope condition. Use this for every condition the server requires (owner scoping, status gates, tenant boundaries).

Multiple calls AND-merge; a later call wins over an earlier one on the same key.

Creates an OrmPaginationInput from any pagination-shaped input — typically the GraphQL wire PaginationInput a resolver received.

When the input is an instance of a @PaginationInputFor-declared class, its declared filter/order allowlists are applied automatically — the declaration on the input type is the single statement of what clients may filter and order by.

Counts entities that match given options. Useful for pagination.

Atomically decrements a numeric column value.

Finds entities that match given find options.

Finds entities that match given find options. Also counts all entities that match given conditions, but ignores pagination settings (from and take options).

Finds first entity by a given find options. If entity was not found in the database - returns null.

Atomically increments a numeric column value.

Returns the largest chunk size that keeps a single statement's bound parameters under the underlying adapter's safe limit. Use this when chunking a large input array in caller code (e.g. for an IN (...) filter or a batched read). Pass 1 for a list of scalar IDs.

Deletes every row in the table.

Requires the target entity to be marked truncatable: true via @OrmTable({ truncatable: true }). Tables that are not explicitly marked as truncatable will throw at runtime.

The confirm: true flag must be passed at every call site to make the intent visible in code review — this method cannot be called without spelling out that a full-table wipe is intended.

Atomically execute a batch of writes against this repository's entity. The build callback receives a builder that mirrors the repo's insert/update/upsert/delete methods but queues operations instead of executing them. Submitted as one atomic batch — D1 maps it to db.batch([...]), other adapters use a native transaction.

Portable across all adapters. The recommended primitive for atomic writes that need to work the same regardless of which database backs the deployment.

Drizzle import specifier — 'drizzle-orm/sqlite-core' or 'drizzle-orm/mysql-core'. Subclasses override.

Helper function name used to construct tables — 'sqliteTable' or 'mysqlTable'. Subclasses override.

After createSchema() runs, returns the assembled pure-drizzle source representation of the same schema. Used by the CLI to write schema.generated.ts — drizzle-kit then reads the file directly with no foundation dependency in its loader path.

Includes the dialect-specific import line (sqlite-core or mysql-core) trimmed to only the helpers actually referenced by the generated tables.

Relations and join-table relations are intentionally NOT emitted: drizzle-kit's migration generation only needs table definitions for SQL DDL. Drizzle's relations() are a runtime query-builder concept that don't affect the database schema.

After createSchema() runs, returns the assembled pure-drizzle source representation of the same schema. Used by the CLI to write schema.generated.ts — drizzle-kit then reads the file directly with no foundation dependency in its loader path.

Includes the dialect-specific import line (sqlite-core or mysql-core) trimmed to only the helpers actually referenced by the generated tables.

Relations and join-table relations are intentionally NOT emitted: drizzle-kit's migration generation only needs table definitions for SQL DDL. Drizzle's relations() are a runtime query-builder concept that don't affect the database schema.

After createSchema() runs, returns the assembled pure-drizzle source representation of the same schema. Used by the CLI to write schema.generated.ts — drizzle-kit then reads the file directly with no foundation dependency in its loader path.

Includes the dialect-specific import line (sqlite-core or mysql-core) trimmed to only the helpers actually referenced by the generated tables.

Relations and join-table relations are intentionally NOT emitted: drizzle-kit's migration generation only needs table definitions for SQL DDL. Drizzle's relations() are a runtime query-builder concept that don't affect the database schema.

Transforms the value from the database to the entity property. Called during entity hydration.

Transforms the value from the entity property to the database. Called during insert/update operations.

Create a new instance of the entity with the given data.

Default: every Drizzle adapter except D1 can wrap writeBatch in a native transaction. D1 overrides this to false (only supports db.batch(), which writeBatch maps to natively).

Convert driver-specific delete result to ORM delete result.

Convert driver-specific insert result to ORM insert result.

Convert driver-specific update result(s) to ORM update result.

Convert driver-specific upsert result(s) to ORM insert result.

Runs a raw query and returns its result rows, normalized from the driver's shape into a plain array. See OrmDatabase.executeRows.

Returns the largest chunk size that keeps a single statement's bound parameters under this.maxSQLVariables, with a 10% headroom for other parameters in the same query. Pass 1 for a list of scalar IDs.

Builds a time-bucketed histogram with conditional counts using direct aggregation.

• Uses GROUP BY on time buckets directly from table data.
• Much faster than CTE + JOIN approach for large datasets.
• Returns OrmTimeSeriesResult format.

Interactive read-write transaction. Throws on adapters where supportsInteractiveTransactions === false (D1). For portable atomic writes, use writeBatch.

Native upsert — single atomic statement using the dialect's conflict resolution syntax (ON CONFLICT DO UPDATE on SQLite/Postgres, ON DUPLICATE KEY UPDATE on MySQL). The dialect-specific work lives in upsertBatch; this is the single-row convenience wrapper.

conditions holds the entity's identifying fields (typically the primary key). It's not a where clause — there's no read involved.

Atomic batch of write operations. Default impl wraps the operations in a Drizzle transaction; D1 overrides to use db.batch([...]) since it has no transaction support. Either way, all operations commit together or none do.