Codegen: has_parent_id lands in the sql namespace but is read at the entity root

Table of Contents

This page is a capture in the discarded bucket of the product backlog — a pre-sprint idea, not yet pulled into a sprint as a story.

1. What

Resolved 2026-09-17. The namespace was fixed rather than the readers, in Route has_parent_id to the entity root and rebind the entities the defect masked, under Fix the has_parent_id feature namespace so profile bindings take effect. The four explicit lines came out, and the eleven flat entities the defect had masked were rebound to a profile that describes them. The capture sits in discarded because the work became a story without being promoted through compass capture promote, so there is no promoted copy for it to point at.

The original text follows.

The profile merger files has_parent_id under sql, because that is what _FEATURE_NAMESPACE says. core.py and the mustache templates read it at the entity root instead. The two disagree, so a profile's assignment never reaches the readers.

A model that drops its explicit has_parent_id line therefore loses its hierarchy function, repository method, handler and service on regeneration. Four models keep the line for this reason. They are business_unit, counterparty and party in refdata, and folder in synthetic.

The fix was to change the namespace, not the readers. The four lines are gone as of 2026-09-17.

2. Why

This blocks the profile from being the single source of truth for hierarchy entities. The binding program exists so a model states only what it decides for itself, and this is the one feature where that does not hold today.

It is also a trap. The line looks redundant to any mechanical survey, because the profile does assign the feature. Removing it is silent at the model level and shows up only as deleted generated code. Regeneration over the four models moved 24 and 8 generated files when the lines came out.

3. References

4. See also

Emacs 29.3 (Org mode 9.6.15)