MemberJunction / MemberJunction/MJ

CodeGen re-renames pre-existing EntityField DisplayNames on unrelated entities

Open
#3,647 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

## 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

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.