Architecture
Mabat (Hebrew for “view”) loads nested, typed data from PostgreSQL, MySQL and SQLite. You declare the view of the data you want as Rust structs; Mabat plans the batched queries that fill it, lets a DBA replace any of them without touching your code, serves the view as JSON or GraphQL, and saves it back — without a session, proxies or lazy loading.
docs/mpa.md) states as numbered rules, the way JPA states the contract of Java persistence providers. Where a page says what Mabat does, it cites the rule — MPA-WRITE-9 — so it can be checked against the specification, and the specification against the tests. The last page is drawn from the specification's machine-readable index, docs/mpa.json, at build time.The question. An ORM maps rows to objects and then decides, while your code runs, which queries to send: it loads lazily, tracks changes through a session, and flushes them later. Mabat takes the other road. What shape of data does a view declare, which queries does it become, who may change them, how do they run concurrently, and how does a value get written back — and how does that compare, point for point, with an ORM?
The sources. The MPA specification v0.1 (docs/mpa.md) and its index (docs/mpa.json), the design document (docs/design.md), and the code of the mabat crates 0.1: mabat-derive (the derive), mabat-core (shapes, plans and SQL, with no database), mabat-sqlx (execution, overrides and writes), mabat-graphql and mabat-cli. The SQL on these pages is what the planner and the writer generate, abridged only where marked.
Regenerating. docs/architecture/overview/mabat-visio.py draws the ten figures as one Visio file (mabat-architecture.vsdx) with the poster kit in docs/architecture/ and its gates; it also writes the SVGs this document references and an EMF per figure for Office. build.sh runs the gates, checks every reference, renders this PDF with Chrome and checks one PDF page per section. Edit the HTML or the script, never the SVGs or the PDF.
Contents
Section titled “Contents”| Page | What it shows | |
|---|---|---|
| 1 | The short answer | five stages from a struct to the database, the same shape the other way for writes, and what that changes compared with an ORM. |
| 2 | A view is a shape | what a declaration says, what is decoded from the row, and what becomes a query of its own. |
| 3 | From shape to queries | the plan of a view, its SQL, and why 20 tasks cost five queries rather than 181. |
| 4 | Tuning without code | override files, the checks that prepare every query at startup, shadow mode, reloads and the command line tool. |
| 5 | Shapes of a result | trees, shared values, graphs with cycles, and two ways to load recursion. |
| 6 | Concurrency | one connection, or a pool of them on one snapshot, level by level. |
| 7 | JSON and GraphQL | selections, the generated schema, and paging the elements of each parent in one query. |
| 8 | Writing an aggregate | the tree of rows, the statements, and optimistic locking with a version column. |
| 9 | Change tracking, against an ORM | an ORM’s session, snapshots and proxies, beside two values compared by generated code. |
| 10 | Three databases | what differs between PostgreSQL, MySQL and SQLite, and what does not. |
| 11 | The contract | every capability against the areas of the specification, read from docs/mpa.json. |