5.2 Response Ordering
The queries backing enumerations and lookups carry no ORDER BY, and a
UNION ALL across the two stores yields rows in whatever order SQLite
produces them. That order is not stable across calls.
The kernel walks enumeration results by dense index across repeated calls, so an unstable order would make that walk duplicate or drop entries. loregd therefore sorts every affected array into a canonical order before encoding a response:
This ordering is a wire-stability guarantee only. It has no bearing on layer resolution, which is order-independent — the kernel selects a maximum, not a first match.
5.2.1 Arrays assembled outside one query #
Two of those arrays are not a single query's result set. They are assembled first and sorted afterwards:
- The blanket-tombstone array in an
RSI_QUERY_VALUESresponse comes from its ownUNION ALL, separate from the value entries it travels beside, and takes the same order they do. - The orphan-GUID array in an
RSI_DELETE_LAYERresponse is the concatenation of every registered hive's orphan set. That walk ranges a Go map, whose iteration order is randomised, so the array is sorted bytewise before it is encoded.
5.2.2 Child display names #
RSI_ENUM_CHILDREN groups rows by child_name_folded and emits one
child block per folded name, carrying a display name taken from the
child_name column.
Where two rows share a folded name but differ in stored case — Foo in
one store and FOO in the other, say — the display name emitted is the
lower of the two bytewise, which is a property of the set rather than of
the order the union produced.
Both
the order of children and the case of the name reported for each are
therefore stable across calls.