MemberJunction / MemberJunction/MJ
CodeGen re-renames pre-existing EntityField DisplayNames on unrelated entities
- Dominant language
- TSQL
- Stars
- 29
- Forks
- 6
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 323
Description
## What happens
Running `mj codegen` over an entity emits `EntityField.DisplayName` reassignments for **pre-existing** columns that have nothing to do with the change being made. The new values are CodeGen's current naming computation; the stored values were computed by an earlier CodeGen era and persisted through the baseline.
Concretely, adding one column to the AI model catalog (PR #3640, `ModelConfiguration`) produced five unrelated renames:
| Entity | Field | Stored | CodeGen wants |
|---|---|---|---|
| `MJ: AI Models` | `AIModelTypeID` | `AI Model Type` | `AI Model Type ID` |
| `MJ: AI Models` | `IsActive` | `Active` | `Is Active` |
| `MJ: AI Models` | `AIModelType` | `Model Type Name` | `AI Model Type` |
| `MJ: AI Model Vendors` | `TypeID` | `Type` | `Vendor Type` |
| `MJ: AI Model Vendors` | `Type` | `Type Name` | `Type` |
The rows carry `AutoUpdateCategory = 1`, so CodeGen legitimately owns them — the defect is not that it writes them, it is that the computed value **disagrees with what a previous version of itself stored**, with no migration ever reconciling the two.
## Why it matters
- Every feature PR that touches an entity inherits a display-name change it did not intend, in both the appended migration SQL and the generated TypeScript doc comments. Deployments get the rename.
- Stripping the assignments does not help: CodeGen re-emits them on the next run, so the diff just migrates from PR to PR. (PR #3640 initially stripped them, then deliberately included them for this reason.)
- It is invisible in review unless someone diffs `DisplayName =` lines specifically — they sit among dozens of legitimate `GeneratedFormSection` updates.
## Suggested direction
Decide which side is authoritative and make it converge once, rather than per-PR:
1. If the current computation is correct, ship a **single** migration that re-normalizes all stale `DisplayName`s repo-wide, so subsequent CodeGen runs are no-ops.
2. If stored values are authoritative (some are hand-tuned — `Model Type Name` reads better than `AI Model Type` for a joined name column), CodeGen should not overwrite a `DisplayName` that diverges from its computation unless explicitly asked.
Either way the goal is the same: a CodeGen run over an untouched entity should produce **zero** `DisplayName` diff.
## Repro
1. Check out a branch that adds a column to `AIModel`/`AIModelType`/`AIModelVendor`.
2. `mj migrate` then `mj codegen --skipfiles` against a database migrated from the v5.46 baseline.
3. Inspect the emitted `CodeGen_Run_*.sql` for `DisplayName = ` on fields you did not touch.
Context: https://github.com/MemberJunction/MJ/pull/3640
Contributor guide
Research direction
Start by running `mj migrate` and `mj codegen --skipfiles` against a database migrated from the v5.46 baseline, then inspect the emitted `CodeGen_Run_*.sql` and generated TypeScript comments for unrelated `DisplayName` changes. Review the behavior around `AutoUpdateCategory = 1` and decide which authority should converge; done means CodeGen on an untouched entity produces zero `DisplayName` diff.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- sql, typescript
- Domain
- database, tooling
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100