pf_app/routes
Paul Trowbridge c6005bd17c Record what a write ran against, and the statement it ran
params says what was asked for. That is not enough to explain a surprising
result, because the same intent produces different rows depending on state
the entry does not carry, and because the translation from intent to SQL is
itself a place bugs live.

So both, not one. env records the state that cannot be reconstructed later:
the territory in force, the version's exclude_iters, and when the template
was generated -- all mutable rows elsewhere with nothing remembering what
they were. sql_text records the statement as executed, territory and scope
already resolved into it.

The template generation is a fingerprint rather than a version. It cannot
bring the old template back; it can tell you the entry did not run under the
current one, which is what would otherwise make a comparison quietly wrong.
Generate SQL has overwritten those templates four times today.

The statement is fetched on demand through GET /log/:logid/debug and left out
of the list, which is opened to scan rather than to read SQL. Under an
entry's payload in the change log there is now an "executed SQL" toggle.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-18 12:19:40 -04:00
..
auth.js Read territory at login, and survive having none 2026-09-18 11:52:00 -04:00
log.js Record what a write ran against, and the statement it ran 2026-09-18 12:19:40 -04:00
operations.js Record what a write ran against, and the statement it ran 2026-09-18 12:19:40 -04:00
sources.js Put the territory column in the Setup editor 2026-09-18 11:38:55 -04:00
tables.js Expose pf_note/pf_op in forecast data; fix tables list duplicates 2026-04-28 19:51:45 -04:00
versions.js Put the fallback display names on the version 2026-09-17 23:47:17 -04:00