5.1 Store Routing
Persistent data lives in the hive database's main schema; volatile data
lives in the attached volatile schema (§3.3). Most operations act on one
of the two, and loregd has to decide which before it can run any SQL.
5.1.1 Operations naming one key #
For a write that names an existing key, the schema containing the key row
selects the store. loregd first probes main.keys by GUID, then probes
volatile.keys only if the first query found no row. A database error is
returned as a storage error, not treated as absence. If an externally modified
database contains the GUID in both stores, the existing main-first lookup
precedence applies; normal key creation rejects such duplicates.
A GUID present in neither produces RSI_NOT_FOUND for most operations.
Routing follows the source table, including when the stored volatile
column contradicts it. A row in main.keys carrying volatile = 1 still
routes writes to main; a row in volatile.keys carrying 0 still routes
writes to volatile. An inconsistent flag must not redirect writes to the
other store.
Rows loregd creates carry the consistent flag for their store. This routing
rule does not repair external metadata changes: read-key and lookup metadata
continue to report the stored column value.
RSI_CREATE_KEY cannot consult a key that does not exist yet, so it
routes on the volatile flag carried in the request instead.
RSI_CREATE_ENTRY routes to the store containing the child key the
entry points at.
When that
child GUID is present in neither store, the entry is written to the
persistent table.
RSI_HIDE_ENTRY routes on the parent key, since a HIDDEN entry
belongs to the parent's child list and a volatile parent's whole subtree
is volatile.
5.1.2 Operations spanning both stores #
RSI_LOOKUP, RSI_ENUM_CHILDREN, RSI_READ_KEY and RSI_QUERY_VALUES
are not scoped to one store: a persistent parent may have volatile
children, and a persistent key may have volatile-store rows beneath it.
Each issues a single UNION ALL statement over the two schemas rather
than querying them separately, so the merge happens inside SQLite.
Nothing de-duplicates across the two stores.
The primary keys that
make (parent_guid, child_name_folded, layer) unique apply per schema,
so if the same triple exists in both, both rows appear in the response.
The
same holds for value entries keyed on (key_guid, name_folded, layer).
The deletions — RSI_DELETE_ENTRY, RSI_DELETE_VALUE_ENTRY and
RSI_DROP_KEY — do not route at all. They delete from both schemas
unconditionally.