Found by an independent adversarial review. Pre-existing in the merged converter (#364).
Converting a real Model to Ossie and straight back renames columns that users see and that other objects reference. Nothing is reported, and structural counts are unchanged, so a round-trip check cannot see it.
Observed, comparing the source Model's columns[].name against the returned document
| Model |
Rename |
58435d2b |
date → Date2 |
04e5abc4 |
Order Number → Transaction ID; Customer Id → Customer ID; Gross Profit ($) → gross_profit_2 |
121d5781 |
Transaction Date → Date |
1740cd61, 9634226d |
Gross Profit ($) → gross_profit_2 |
58435d2b shows why this is more than cosmetic: the Model's own lesson_plan_string entries still reference the old name — "What were [sales] by [product] [date].'this year'" — so the saved questions break against the returned Model.
Two causes
-
The model-level unattributed_formulas stash records the formula's name, not the name of the column that surfaces it. On the way back the column is rebuilt from the formula name. Nothing is reported.
-
gross_profit_2 is the converter's own collision suffix tripping its own staleness check. It logs TS-STASH-TML-NAME-STALE, whose message claims the column "was renamed" — and that claim is false; nothing renamed it but this converter.
Why existing checks miss it
Table, column, formula and join counts are all unchanged, so a structural comparison reports no loss. The round-trip harness I use reported losing structure 0 for the same run. Only comparing the names catches it.
Found by an independent adversarial review. Pre-existing in the merged converter (#364).
Converting a real Model to Ossie and straight back renames columns that users see and that other objects reference. Nothing is reported, and structural counts are unchanged, so a round-trip check cannot see it.
Observed, comparing the source Model's
columns[].nameagainst the returned document58435d2bdate→Date204e5abc4Order Number→Transaction ID;Customer Id→Customer ID;Gross Profit ($)→gross_profit_2121d5781Transaction Date→Date1740cd61,9634226dGross Profit ($)→gross_profit_258435d2bshows why this is more than cosmetic: the Model's ownlesson_plan_stringentries still reference the old name — "What were [sales] by [product] [date].'this year'" — so the saved questions break against the returned Model.Two causes
The model-level
unattributed_formulasstash records the formula's name, not the name of the column that surfaces it. On the way back the column is rebuilt from the formula name. Nothing is reported.gross_profit_2is the converter's own collision suffix tripping its own staleness check. It logsTS-STASH-TML-NAME-STALE, whose message claims the column "was renamed" — and that claim is false; nothing renamed it but this converter.Why existing checks miss it
Table, column, formula and join counts are all unchanged, so a structural comparison reports no loss. The round-trip harness I use reported
losing structure 0for the same run. Only comparing the names catches it.