Codegen entity meta-model — C++ presentation

Table of Contents

This page is a segment of the Codegen org-entity meta-model hub, covering the two facets behind one generic-history flow: the ores.cpp.presentation facet, which renders a domain type to an ordered field list, and the ores.cpp.history-provider-registrar facet, which registers the server-side history provider that feeds that list. It exists to answer one question: when the history dialog shows "what changed between version 3 and version 4", what does it show, in what order, and where does the server side of that history come from?

1. Physical model mapping

Facet Description
ores.cpp.presentation Server-side rendering of a domain type for display: history field mapper.
ores.cpp.history-provider-registrar Server-side registration of one entity's history provider into the ores.history dispatch registry.

2. What gets generated, unconditionally

A history field mapper: a function rendering the entity to an ordered list of (field name, value) pairs, in mapper order, with no runtime reflection. The Keys and columns declarations drive the field list directly — there is nothing further to configure.

Generates, in badge_definition_history_field_mapper.hpp:

namespace ores::dq::presentation {

/**
 * @brief Renders a badge_definition to an ordered field list for
 * history-diff display. One line per field, in mapper order; no
 * runtime reflection.
 */
[[nodiscard]] ORES_DQ_CORE_EXPORT std::vector<ores::diff::domain::field_value>
render_badge_definition_fields(const domain::badge_definition& v);

}

No paste blocks or behavioural knobs exist for the mapper today.

A history-provider registrar pair: a function registering the entity's history provider into the ores::history::service::dispatch_registry under the product.component.entity_singular type key. The provider reads the entity's version history through its service and renders each version through the mapper above, so the two facets share one model and one mapper function. The registrar pair is a server-side registration surface: the per-component service registrar calls each per-entity function, which is why every mapper-bearing entity needs the pair even before it is wired into that aggregator.

Generates, in badge_definition_history_provider_registrar.hpp:

namespace ores::dq::messaging {

void register_badge_definition_history_provider(
    ores::history::service::dispatch_registry& registry);

}

The mapper set and the registrar-pair set are equal by construction: both facets admit the same domain_entity model. An unwired pair in the aggregator just stays unregistered at runtime.

3. See also

Emacs 29.3 (Org mode 9.6.15)