[lesomnus]

From the review of lesomnus/payday#84's work, item T5-4.

Builds on protobuf-orm/ent#16, which is merged: internal/apptest pins its merge commit, b333b8f.

What was wrong

A generated write inside a transaction somebody else began joins it, and its Close does nothing there. There are no savepoints, and ending that transaction is not the write's job. So a write that failed after it had begun writing left what it wrote in the transaction:

• the row of an Add whose record was refused;
• the UPDATE of an Apply whose read after it failed;
• the first few hundred rows of an AddMany whose next INSERT was refused.

PostgreSQL takes the transaction with a refused statement. SQLite undoes the statement alone, and a failure that is not a statement's undoes nothing on either engine. A caller that went on and committed committed part of a write it had been told had failed.

AddMany also wrote every statement first and recorded after. The rows of a statement that held sat in the transaction with nothing recorded of them until the last statement held; when a later statement was refused, that never happened. payday's trail is such a recorder, so those rows were written past the trail.

What changes

• Every write says tx.Writing() before its first statement that writes (ent.Joined.Writing, dialect: a transaction's end is its owner's -- BeginTx refuses a foreign one, and joined work that failed partway refuses the commit ent#16):

  • Add, before its INSERT;
  • AddMany, before its first INSERT;
  • Apply, before its UPDATE, when the document writes;
  • Erase, before its DELETE or its stamp.

  A Close with no Commit after that refuses the commit of the transaction the write joined (ent.ErrPartial), when that transaction was begun with dialect.BeginTx.

• What does not refuse:

  • A write that fails before it writes refuses nothing.
  • A write that began its own transaction is taken back by its Close, as before.
  • A transaction that keeps nothing (a generated Client.Tx) is its owner's to answer for.

• Writing() goes before the statement, not after it. A statement refused on its own is then answered the same way on SQLite as PostgreSQL answers it.

• AddMany records the rows of each statement as soon as it holds, before the next statement is sent. Nothing is in the transaction that is not recorded, and what a failure leaves behind is refused its commit.

• Docs: the README and the AddMany doc say so.

Tests

internal/apptest/server/bare/x-partial_test.go runs each case in a transaction begun with BeginTx (SQLite, where a refused statement does not end the transaction):

• An AddMany of 501 whose second statement is refused has recorded the 500 rows of the first, its commit is refused, and nothing holds.

• The commit is also refused after:

  • an Add whose record is refused;
  • an Add the database refuses (a duplicate alias);
  • an Apply whose record is refused;
  • an Erase whose record is refused.

  Nothing of any of them holds.

• A write refused before it wrote (an AddMany item that cannot be a row) refuses nothing.

• A write that held refuses nothing either.

Mutations, each made in the generated user.g.go and each caught:

• Writing taken out of AddMany, of Add (both Add cases fail), of apply, and of Erase;
• the record moved back to after every statement rather than after each (the "500 recorded" check fails).

Locally: buf generate twice and go generate ./... in internal/apptest, with nothing moved; go test ./... in the root, runtime and internal/apptest, all passing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KxtnpRW533bdErnW8QPhsk