Codegen entity — post-generation checklist

Table of Contents

Summary

Codegen produces every file an entity needs, but it does not wire the generated functions into the running application — a handful of call sites are hand-maintained by design, and forgetting one produces no compile error, only a silently-missing feature at runtime. This page is the fixed checklist of those call sites: what to add, where, and why each one isn't generated yet (with a pointer to the capture/task tracking its eventual automation, where one exists). Work through it for every newly-commissioned entity.

Detail

Sub-registrar: NATS command handlers

ores.cpp.nats-handler/ores.cpp.nats-sub-registrar generate register_<entity>_handlers(), but nothing calls it. Add one call inside the component's aggregator (mirrors ores::refdata::core::messaging::registrar) so application.cpp keeps collapsing to a single call regardless of how many entities the component owns. Not automated: each component's aggregator differs enough (constructor arguments, ordering) that a generic dispatch-table pattern is tracked separately — see capture Generic dispatch-table registrar pattern.

Event-registrar: NATS changed-event relay

ores.cpp.nats-event-registrar generates register_<entity>_event_mapping(), bridging the entity's Postgres LISTEN=/=NOTIFY channel to the in-process event bus. Add one call in the component's application.cpp, alongside the sub-registrar call above. This one is easy to miss precisely because forgetting it produces no symptom at all until a consumer notices it never receives change events — see AA97E310 (PRs #1571/#1590), which found party_type and ~14 other entities silently never fired eventing for exactly this reason. Not automated: same generic dispatch-table pattern above would cover this call site too.

CMake: new component/library wiring

A component's own CMakeLists.txt (root/src/tests/modeling) is generated by ores.cmake.component, but that generated file still has to be add_subdirectory-d from its parent's CMakeLists.txt the first time a component is created — a one-time step per new component, not per entity.

Qt plugin: menu/window wiring

A newly-generated entity's Qt ensemble (ores.cpp.qt: MDI window, detail dialog, controller, client model) needs its window instantiated and its menu entry added by the owning component's Qt plugin (e.g. RefdataPlugin, DqPlugin) — this wiring is plugin-specific hand-written code, not generated. A new component's plugin is itself a one-time prerequisite, not a per-entity step, once it exists.

See also

Emacs 29.3 (Org mode 9.6.15)