MemberJunction / MemberJunction/MJ

CodeGen: SS migration artifacts and the PG bake regenerate from different metadata states — same migration, diverging function signatures

Open
#3,514 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.