Return 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
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.
Entity registration, transactions and graph/variant write entry points.