pf_app/lib
Paul Trowbridge 19e52fa3fe Carry every date column through an adjustment
Scale and recode wrote dataCols, which held dateCols[0] and nothing else.
On a source with order, requested and ship dates that means every scale and
recode row was written with rdate and sdate_e null -- not stale, absent --
while the period dimensions derived from them (rseas, smon_e) were copied
with the other dimensions and so read perfectly, which is what kept it out
of sight.

Both columns are role 'date' and therefore sliceable, so an adjustment
scoped to a ship date matched no adjustment row that had ever been
written, and anything dating the forecast by ship date dropped every
adjustment without saying so. Clone already carried them all, for the
date_offset it has to shift; the loads always did.

The GROUP BY widens with the select list. On osm_skinny that is 971,185
groups against 971,352 -- ordnum and ordline already make a row nearly
unique -- so the row count is unaffected in practice.

Existing rows are not repaired; see Known issues.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-21 09:19:09 -04:00
..
auth.js Scope what an account can see and change to its territory 2026-09-18 11:14:03 -04:00
sql_generator.js Carry every date column through an adjustment 2026-09-21 09:19:09 -04:00
utils.js Read source columns from pg_catalog, not information_schema 2026-09-18 16:12:05 -04:00