Profile: Read model

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

A list screen shows one row that joins several tables. A read model answers that row with one query that the service pages, sorts and filters. The row has no table of its own, so nothing writes it, nothing versions it and nothing announces a change to it.

The profile keeps the read-only current-state surface: list, get and get_many, with no write verb and no version read. It replaces the table with a view. The model states the select in its * SQL ** View section, and the generated view is security_invoker, so the tenant policies of the base tables apply to the caller.

2. Reference entity

None yet. The first model to bind it is the trade summary, in ores.trading.

3. Assignments

Feature Value
read_only true
current_state true

4. Physical space

One row per physical-space address this profile fixes admission for – any address not listed here is left to whatever else resolves it. A bound entity's own Physical space table (if any) always wins over these.

Address Enabled
ores.sql.schema.domain_entity_create false
ores.sql.schema.domain_entity_drop false
ores.sql.schema.domain_entity_view_create true
ores.sql.schema.domain_entity_view_drop true
ores.sql.schema.notify_trigger false
ores.sql.schema.notify_trigger_drop false

A view has no rows of its own to announce, so the eventing facets go with the notify trigger. A hard gate in resolve_targets withdraws them, for the same reason as for the staging profile: a shape profile fixes ores.cpp.eventing-integration-test to true, and two profiles that fix one address differently are a binding the loader refuses.

5. See also

Emacs 29.3 (Org mode 9.6.15)