ores.refdata generated SQL/C++ is stale vs current codegen templates
Table of Contents
This page is a capture in the discarded bucket of the product backlog.
Resolved (discarded 2026-08-09): The stale-generated-code issue was
fixed by the subsequent refdata drift/regeneration work.
refdata_rounding_types_create.sql is now stamped
sql_schema_domain_entity_create.mustache, renders
clock_timestamp(), and carries the rounding_types_name_uniq_idx
unique index this capture flagged as a real correctness improvement
(commits 8aecfd41b "Regenerate rounding_type/purpose_type/
day_count_fraction_type/business_centre against current templates" and
1f4fc2859 "Eliminate all ores.refdata generation drift").
What
Sanity-checking a .org model migration by actually regenerating (not
--dry-run) ores.refdata.rounding_type and ores.refdata.party
against ores.sql.schema=/=ores.cpp.domain=/=ores.cpp.repository
produced large diffs against the checked-in generated files —
refdata_rounding_types_create.sql is still stamped
Template: sql_schema_create.mustache while the current template is
sql_schema_domain_entity_create.mustache, which renders
clock_timestamp() instead of current_timestamp, uppercase
NEW=/=OLD record references, an added
rounding_types_name_uniq_idx unique index, and richer header
comments. Do a dedicated regenerate-and-review pass across all of
ores.refdata's domain_entity models (SQL + C++ domain/repository/
service/Qt), verifying behavioural diffs (the unique index in
particular looks like a real correctness improvement, not just
formatting) before committing.
Why
Discovered while doing task Downgrade address/model-type incompatibility to skip in –component mode: the checked-in generated code no longer matches what the current templates would produce, independent of any key-shape migration. Left un-actioned there deliberately — it's a much larger, separate change (potential behavioural SQL diffs across every refdata entity) than that task's scope.
References
- Task: Downgrade address/model-type incompatibility to skip in –component mode — where this was found.