Table

Typed references to this table's columns, for indexes and for the query DSL.

Emitted by the macro in declaration order, which is the order NamedTuple.From[T] uses, so a label always names the column beside it.

offset is the 1-based JDBC index of this row's first column.

The row's primary key, read from the mandatory id field. Emitted by the macro, because only it knows the field exists — the trait cannot express "has an id".

Strict, and deliberately so: a lazy result would hold the scope and escape the block that created it. A cursor arrives with the query DSL (DESIGN §9), declaring its capture.

The count rather than an exception, for the reason updateById gives: a missing row is an answer, and only the caller knows whether it matters.

eezo deletes by primary key and tracks no versions, so an update that lands first is erased by a later delete without either writer learning of the other: the edit is lost silently. An update that lands after the delete is not silent, it sees 0. Here 0 says only that the row was already gone.

The table wipe.

Deleting takes a predicate, always. There is no delete() terminal on Query, so a dropped .where during a refactor cannot silently become a table wipe — it stops compiling. DESIGN §9.4, and §3.6: destructive and risky are different, and the destructive one says its own name.

CRUD by primary key, as extensions on the derived Table[T]. DESIGN §8.2.

Extensions rather than methods on the trait, so that Table[T] stays a plain description: the migration layer, the differ and Form[A] all consume it, and none of them should acquire a dependency on a transaction capability. Reading requires DB, writing requires Tx, and TxCap <: DBCap is what lets a read sit inside a transaction and not the reverse.

No Database appears in any signature here. The scope came from transact or read.

CRUD by primary key, as extensions on the derived Table[T]. DESIGN §8.2.

Extensions rather than methods on the trait, so that Table[T] stays a plain description: the migration layer, the differ and Form[A] all consume it, and none of them should acquire a dependency on a transaction capability. Reading requires DB, writing requires Tx, and TxCap <: DBCap is what lets a read sit inside a transaction and not the reverse.

No Database appears in any signature here. The scope came from transact or read.

CRUD by primary key, as extensions on the derived Table[T]. DESIGN §8.2.

Extensions rather than methods on the trait, so that Table[T] stays a plain description: the migration layer, the differ and Form[A] all consume it, and none of them should acquire a dependency on a transaction capability. Reading requires DB, writing requires Tx, and TxCap <: DBCap is what lets a read sit inside a transaction and not the reverse.

No Database appears in any signature here. The scope came from transact or read.

Starts a query. Table[Book].where(...) is shorthand for Table[Book].query.where(...).

Writes every column of row, matched by its own key.

The later write wins: two edits to different fields of the same row end with the second overwriting the first, including fields it never touched. That is the accepted default (DESIGN §8.6). A count of 0 is the one conflict it can still report, and it is where an optimistic concurrency check would later answer too: a version in the where turns a stale write into the same 0, so the signature would not change.

The row to write found by id rather than by the key inside row.

The two coincide for every caller inside db, which is why update exists at all. They come apart at core's Store[A], whose update(key, row) promises to replace "the row under key": binding id here is what makes a stale key report false rather than write to row's own key and report true, which is the answer the in-memory half gives.

The count comes back rather than an exception because a write that matched nothing is an answer, not a failure. The caller that cares asks, and raising would have rolled back every other write in the same transact over a row that was simply not there.

0 is also all the conflict detection there is. eezo writes by primary key and tracks no versions, so when two writers edit the same row both see 1 and the later one wins silently: the earlier edit is lost without a trace. 0 says only that the row was never inserted or that something deleted it after it was read.

CRUD by primary key, as extensions on the derived Table[T]. DESIGN §8.2.

Extensions rather than methods on the trait, so that Table[T] stays a plain description: the migration layer, the differ and Form[A] all consume it, and none of them should acquire a dependency on a transaction capability. Reading requires DB, writing requires Tx, and TxCap <: DBCap is what lets a read sit inside a transaction and not the reverse.

No Database appears in any signature here. The scope came from transact or read.

Every row in primary-key order, which is what core's Store[A] promises all() returns. Separate from selectAllSql, because db's own all is deliberately unordered and the query DSL's caller states its own order.