Optionalopts: {Optionalcolumn: Raw<any> | ColumnRef<EntitySchema<TEntity>>Optionalcolumn: Raw<any> | ColumnRef<EntitySchema<TEntity>>Look up a single entity by primary key. Returns undefined when no
row matches.
The PK column(s) are resolved automatically from the entity's schema
via the primaryKey / hasPrimaryKey extensions. Composite PKs are
passed as a tuple in declaration order:
await db.todos.find(42); // single PK
await db.userRoles.find([userId, role]); // composite PK
Any chained .include() / .includeVariant() calls on this query
are honoured by the underlying SELECT.
Look up multiple entities by primary key in a single SQL statement.
Returns rows in DB order (no ordering guarantee relative to pks).
For composite PKs each element of pks is a tuple matching
declaration order. Returns [] when pks is empty.
Like find but throws EntityNotFoundError when no row matches.
Eager-load a relation declared on TEntity via .hasOne() /
.hasMany() / .belongsTo() / .belongsToMany(). Selector returns
the relation key as a string literal.
Optionalcustomize: (q: SchemaQueryBuilder<any, any>) => voidEager-load a relation declared inside a polymorphic variant (CTI/STI).
The relation is only populated on rows whose discriminator matches
variantKey. Type-level: when relationName is a key of the
entity's relations, it appears only on the matching branch of the
discriminated-union result; otherwise the result type is unchanged.
Optionalcustomize: (q: SchemaQueryBuilder<any, any>) => voidReturn a typed variant view pre-filtered to variantKey.
Behaves like EF Core's Set<DerivedType>(): all reads automatically
filter by the discriminator value, and insert / update / delete
apply the correct single-table (STI) or two-table (CTI) logic.
const assigned = db.activities.ofVariant('assigned');
// Insert a new variant row (discriminator set automatically):
await assigned.insert({ todoId: 42, userId: 7, assigneeId: 9 });
// Update variant-specific columns for matching rows:
await assigned.where(t => t.id, activityId).update({ assigneeId: 10 });
// Delete variant rows (CTI: variant table first, then base):
await assigned.where(t => t.id, activityId).delete();
// Find by PK (result is narrowed to the variant branch):
const a = await assigned.find(activityId);
// a.type === 'assigned' and a.assigneeId is available
Optionaldirection: "asc" | "desc"Allocate a fresh EntityQuery (rarely needed; method shortcuts on the
DbSet itself already do this).
Persist a nested write graph (root + related entities) in a single transaction. Each node is INSERTed when its primary-key fields are absent and UPDATEd when they are present (composite-PK aware).
Topology:
belongsTo parents are saved first; their PKs feed the root's FK.hasOne / hasMany / belongsToMany children inherit the root's
PK into their FK column.belongsToMany children may be passed as full nested graphs (new
rows) or as { pk: value } references (link existing rows).If called inside an existing transaction (via withTransaction), the
outer transaction is reused; otherwise a fresh one is opened and
automatically rolled back on failure.
Optionalbindings: any[]Optionaloperator: stringOptionalvalue: any
Typed query starter for a registered entity. Structurally it behaves like a fresh EntityQuery — every method invocation allocates a new underlying
SchemaQueryBuilderso chains stay isolated.Additional members beyond
EntityQuery:entity— the wrapped Entity definition.query()— explicit factory for a freshEntityQuery(rarely needed).withTransaction(trx)— return a newDbSetbound to a transaction.