MemberJunction / MemberJunction/MJ
CodeGen: SS migration artifacts and the PG bake regenerate from different metadata states — same migration, diverging function signatures
- Dominant language
- TSQL
- Stars
- 29
- Forks
- 6
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 323
Description
## One sentence
SQL Server migration artifacts are CodeGen'd from the author's **live dev database** (metadata *ahead* of the committed chain), while the PostgreSQL bake regenerates functions from the **chain's replay state** (metadata *behind*) — so the two sides of the same migration can disagree about a function's parameter list, and the disagreement only surfaces when a later metadata sync calls the parameters the PG side never grew.
## The receipt (6.1.0-edge.0 release night, 2026-08-05)
- SS `V202608050100` ships `spUpdateEntity` with **91 parameters**, including `@ExternalDataSourceID` / `@ExternalObjectName`.
- The PG bake of the *same migration* produced **87 parameters** — without them.
- The replayed chain contains **zero** `EntityField` rows for those two columns: the metadata that would describe them never rides any committed migration, which is exactly what starved the PG generator.
- Failure mode: the release's metadata-sync migration then calls `spUpdateEntity` with the missing parameters → the PG counterpart fails to apply on a clean database. Ten call sites needed a strip-args + direct-`UPDATE` repair to ship the counterpart.
## Why it recurs
Any time an author's dev DB carries schema/metadata ahead of the committed migration chain (a normal state during development), SS CodeGen bakes that drift into the SS artifact. The PG conversion pipeline deliberately replays only committed history — the correct choice for reproducibility — so every such sync produces a silent SS↔PG signature skew until a later call trips over it.
## Directions worth evaluating (not mutually exclusive)
1. **Parity of inputs:** generate SS artifacts from chain-replay state too (clean-room CodeGen), so both sides see identical metadata. Strongest fix; changes the authoring workflow.
2. **Conversion-time assertion:** when baking PG, cross-check every parameter referenced by the migration's sync statements against the replay-state function signatures and fail loudly with the missing-metadata diagnosis, instead of shipping a signature that will fail later.
3. **Author-side gate:** detect "dev DB metadata not represented in the committed chain" before a sync migration is committed (the drift itself is the defect from the chain's point of view).
Found while producing the PG counterpart for the first Edge release; the repair pattern and diagnosis recipe are documented in the release-engineering material.
🤖 Filed with [Claude Code](https://claude.com/claude-code) on Craig's approval (review queue, 2026-08-06)
Contributor guide
Research direction
Start with the SQL Server CodeGen and PostgreSQL conversion pipeline, using the release-engineering material and the migration sync statements described in the issue. Compare their metadata inputs and replay-state function signatures, then verify on a clean database that the chosen parity, assertion, or author-side gate prevents divergent signatures from reaching a later metadata sync.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- postgresql, sql
- Domain
- build-system, databases
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100