jonnify·bcs /bcs/elixir-core/relations

B2.3 · dive 3 of 3

Relations are systems.

A relation is not a field on either entity. It is its own owning process — a row keyed by the pair of branded ids, both ends gated, indexed both ways.

A relation owned by a process, keyed by the pair, dual-indexed. Select a part.
PRT0KHT…portfolio AST0KHT…asset gated EchoData.Bcs.EdgeStorerelation: holds {PRT0KHT…, AST0KHT…}→ {since, qty} fwd: PRT → ASTrev: AST → PRTtwo private ordered_sets
readout · Select a part. A relation is its own system: a row keyed by the pair of names, both ends gated, indexed both ways.
§1

The idea

echo_data · bcs/edge_store.ex

The component-system tradition kept a relation as a list of ids embedded in an entity — the fat struct returning by another door. In BCS a relation is a system of its own. EchoData.Bcs.EdgeStore is one owning process for one kind of edge; portfolio holds asset is a row keyed by the tuple of the two branded ids, carrying its own properties, embedded in neither endpoint.

The relation has a type, and the type is enforced at its boundary. The store is configured with a relation and the namespaces it joins; the subject and object ids are gated on the way in, so a mismatched end is refused before the edge is written. A relation can only be drawn between the kinds it is declared to hold, and the wrong-kind edge is a checked error.

An edge store keeps two private :ordered_set indexes, forward and reverse. A subject’s edges are a key-range read on the forward index; an object’s back-references are a key-range read on the reverse one; a delete clears both directions together. The relation is readable and countable from either side, owns itself, and is referenced by id from the entities it joins — never embedded in them.

The three dives are in the module: B2.5 · Relations Are Systems.

§4

The doors

the sibling courses
§2

References

sources · related

Sources

Related