save(only=) / save(exclude=) emit columns in set order, so the UPDATE text changes between runs #776

Problem

save(only={...}) and save(exclude={...}) take a set of column names, and the UPDATE they send lists the columns in that set's iteration order, which changes between Python processes:

await account.save(only={"label", "balance"})
# one run:     UPDATE "account" SET "label" = $1, "balance" = $2 WHERE "id" = $3
# another run: UPDATE "account" SET "balance" = $1, "label" = $2 WHERE "id" = $3

The row ends up the same, but the statement text does not. That surfaced while pinning the Mutations guide's SQL blocks (#725, PR #775): the docs test has to run with PYTHONHASHSEED=0 to get a stable statement, and the page tells readers the column order is not fixed. The statement log and .sql() show a different statement for the same call from one process to the next, which makes log diffs and any test asserting on the SQL flaky.

What this asks for

A write's column order is a function of the model, never of a set's hash order: only= / exclude= columns are emitted in the model's field declaration order (the order save() without only= already uses). Then the docs test drops PYTHONHASHSEED=0, and the Mutations page's sentence about unfixed order goes.

Worth checking at the same time: any other write that takes a set (bulk_create with only=/exclude=, if it does) and whether update(**fields) follows the call's keyword order (it should: keyword order is deterministic).

Related

• Show captured SQL beside query and mutation examples (needs #700) #725 / PR docs: show the SQL each query and mutation sends, regenerated by a test (#725) #775 (where it surfaced), SQL inspection and logging: print or log the SQL Ferro renders and runs for a query or mutation #700 (the statement log makes the instability visible).
• The worker on Show captured SQL beside query and mutation examples (needs #700) #725 also noted that exists() sends COUNT(*) rather than SELECT 1 … LIMIT 1 (a performance observation, not a correctness one), and that a batch update() does not refresh an instance the session already holds (identity-map staleness after a set-based write). Both may deserve their own issues.