pf_app
Paul Trowbridge
496642c545
The change log joined the whole forecast table on every open to total rows it had just written -- 2.5M rows to report a few thousand, and the Baseline page's row and value columns paid the same cost again. The totals go onto pf.log at write time instead. This is not a cache that can drift: a log entry's forecast rows never change once written, because only the operation owning the logid inserts them and the only thing that removes them is undo, which deletes the log row too. measure_cols records which columns the figures are denominated in, since the value and units roles can be reassigned in col_meta and the numbers would otherwise quietly come to mean something else. Stamping is best-effort and runs after the commit: a failure to record what happened must not roll back the thing that happened. The loads return their new log id to make it possible, the adjustments take theirs from the rows they return, and apply_mode 'each' writes one entry per slice, so it is a set rather than a single id. ?recount=1 does it the old way and writes back what it finds. Stored totals cannot drift on their own, but nothing stops someone deleting forecast rows by hand, and a stored figure has no way to notice -- so there is a way back, which doubles as the backfill for entries written before the columns existed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| lib | ||
| public | ||
| routes | ||
| setup_sql | ||
| ui | ||
| .env.example | ||
| .gitignore | ||
| CLAUDE.md | ||
| install.sh | ||
| package-lock.json | ||
| package.json | ||
| PERSPECTIVE.md | ||
| pf_perspective_options.md | ||
| pf_spec.md | ||
| pf.sh | ||
| server.js | ||