Profile: Table-less record

Table of Contents

This page is a named element-scope MASD profile instantiating ORE Studio Variability Model § "Profiles: naming a recurring configuration point". A model file binds to this profile (rather than authoring each feature individually) to guarantee the exact feature combination below, with no ad hoc variation.

1. Purpose

Some records cross the wire without ever being stored. A diff engine's rendered field, a byte span, a change entry, and the result holding those entries: each is a member of a response and nothing else, so it has no table, no repository, no service, no handler, no subject and no screen. Before this profile they could not be modelled at all, and their C++ and TypeScript twins were both written by hand – which is how a std::size_t came to project as a TypeScript type named Size_t, and how the two twins could drift with nothing to check them.

Four records need the same combination, which is what makes it a profile rather than a local choice.

Binding it is enough. The profile reaches :no_audit_columns: through the Assignments table, and that flag drops the version column and the audit tail – recorded_at included, because a record with no actor has no use for a transaction timestamp. A model bound to it carries its own members and nothing else.

2. Reference entity

diff_span – the smallest of the four, and the shape the others compose: two byte offsets, no key, no table, no behaviour.

3. Assignments

A table-less record is not an entity: it has no tenant, no workspace, no manufactured key and nothing to page or annotate. Any feature not listed is left to the model's own choice, and a model bound to this profile declares only its members.

Feature Value
has_tenant_id false
has_workspace_id false
system_scope false
nullable_tenant_id false
has_uuid_primary_key false
has_change_reason_cache false
has_pagination false
no_audit_columns true

4. Physical space

One row per address this profile fixes admission for. A record with no table has no SQL, no repository, no service, no handler, no protocol, no subject, no screen and no trigger, so the root row disables everything and two facets are let back in.

The six explicit disables are not decoration. Admission is resolved in two steps, and the first one is not re-opened by the second: compute_supported_set asks whether the facet is enabled and drops the whole facet when it is not, before any archetype is considered. So a root disable plus ores.cpp.domain.class_header enabled yields nothing at all – the facet was already dropped, and the more specific override is never consulted. The facet must be enabled, and the archetypes it brings that this profile does not want named individually.

Address Enabled
ores false
ores.cpp.domain true
ores.cpp.domain.json_io_header false
ores.cpp.domain.json_io_impl false
ores.cpp.domain.table_header false
ores.cpp.domain.table_impl false
ores.cpp.domain.table_io_header false
ores.cpp.domain.table_io_impl false
ores.ts.domain true

5. See also

Emacs 29.3 (Org mode 9.6.15)