pipekit/config
Paul Trowbridge 09056bea9d Sync the RM apply tables, rm30201 incrementally
rm20201 (Applied Open) is 985 rows and stays a full reload. rm30201
(Apply History) was a full pull of 1,149,405 rows taking 19 minutes; it
now moves 661 rows in 6 s and reconcile --quick ties on all 108 metrics.

Neither apply table has DEX_ROW_TS, so rm30101's pattern does not port.
DEX_ROW_ID catches inserts but never moves on an update, so a 7-day
GLPOSTDT/APFRDCDT window carries restated and back-posted applies.
APTODCDT belongs to the apply-to document and lags by weeks; DATE1 has
163 rows dated to year 6201.

The pull is document-grain, not row-grain. merge_key is (aptodcty,
aptodcnm), so the DELETE clears every apply row for a document, and
staging only the row that matched would drop its siblings -- ~16k of
1.13M docs carry more than one. AK1/AK5 lead on those two columns, so
the EXISTS is an index seek.

Uses OPENQUERY pushdown rather than the four-part linked-server name: an
aggregate through the four-part name ran past 2 minutes against 1.3 s
pushed down. Note no apostrophes may appear inside the OPENQUERY string,
comments included.

Unapplies remain uncovered -- they delete the RM30201 row and write one
back to RM20201, and delete-by-key cannot see a row that is gone. The
985-row rm20201 reload is the cross-check.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 23:48:22 -04:00
..
modules Sync the RM apply tables, rm30201 incrementally 2026-08-18 23:48:22 -04:00
connections.json updates 2026-08-06 15:39:22 -04:00
drivers.json feat: version-control pipeline definitions via export/apply 2026-07-22 10:56:55 -04:00
groups.json updates 2026-08-06 15:39:22 -04:00