B2.2 · Property Stores on ETS — manuscript chapter 2.2
The substrate becomes the database.
Three system tables under one tree — AST instruments, PRT balances, ORD orders — with the branded id as the only key, chronology as a property of the keyspace rather than a column, and exactly one amendment to the store module: window/3.
The chapter is content/bcs2.2.md; the rung behind it is bcs2.2
(bcs_rung_2_2_check.exs), its committed transcript closes PASS 5/5 — and the
2.1 rung re-runs green under the grown surface. Every figure on this module's pages is verbatim from
those outputs.
The desk's three questions
content/bcs2.2.md · WhyA newest-first page
What are the latest orders is a page off the table tail — page_desc/2, a
prev walk from the table's end, no timestamp column consulted.
A window
What happened between 14:30 and 14:32 is a half-open window — two synthetic cursors and
one gated select, window/3.
A get by name
What is this instrument is get/2 — the branded id is the only key, so the
name is the lookup.
A database that needs a timestamp column, an index on it, and a query planner to answer the first two has paid three times for what the keyspace already carries. The part preface's guideline — a table keyed by branded ids is a timeline, add no second clock — is cashed here as working reads on real stores.
The proof
content/bcs2.2.md · quoting bcs_rung_2_2_check.outFive gates over three real stores: the database's shape, the only-key law, both chronology reads, and the review itself. The committed transcript:
boot: three system tables under one tree -- AST instruments, PRT balances, ORD orders P1 shape ok -- instrument and balance rows live behind their own boundaries; values are private representations P2 key ok -- the branded form is the only key: the same snowflake's decimal rendering refused as :invalid P3 order ok -- newest five by byte order equal the last five minted: no timestamp column consulted P4 window ok -- window [tA,tB) by synthetic cursors returned 100 of 100 expected, ascending by key P5 review ok -- surface grew by exactly one export: window/3 -- the review Chapter 2.1's decision required, performed PASS 5/5
A gate line is a recording of what the store refused or returned on stage, committed beside the script that produced it. The amendment behind P5 was performed the way Chapter 2.1's decision requires — as an architecture review with the surface gate as its instrument — while the 2.1 rung re-runs green under the grown surface.
The dives
three lessons, fixed by the chapter specThe Only Key
P1 the database shape — values are private representations — and P2 the decimal rendering refused
:invalid: the third door closed at the ingress, after storage (1.3) and CPU
(Appendix 1.1).
Chronology Without a Column
P3 the newest five by byte order; P4 window/3, [lo, hi) half-open, 100
of 100 ascending — the order theorem as a read path, with the real match spec and its Go
counterpart.
The Review, Performed
P5 the surface grew by exactly one export; the three desk reads; the frozen-record ethic — the 2.1 transcript as the pre-amendment surface evidence.
Reach for get/2 when the name is known, page_desc/2 when
the question is latest, window/3 when the question is between — and no
fourth read has earned an export yet, which is the review bar working. The moment who holds this
asset becomes a question, the pair is a relation, and Chapter 2.5 owns it.
References
sources · relatedSources
- Erlang/OTP — the ets moduleordered_set term order; select/2 and match specifications; protection levels
- Erlang/OTP — the supervisor behaviourthe one tree the three stores run under
Related
- B2 — The Elixir BCS Corethe chapter landing; the Part II arc
- BCS — the course homethe law, the id anatomy, the chapter map
- Redis Patterns Appliedthe storage economics under the keyspace
- Functional Programming in Elixirthe umbrella where echo_data lives