Mabat

Mabat (מבט) is Hebrew for “view”. You describe the shape of an aggregate — a task with its assignee, its subtasks and their notes — and Mabat loads it with one query for the roots and one batched query per relationship. It never runs one query per row, and it never joins two collections into a cartesian product.

#[derive(View)]
#[view(table = "task")]
struct TaskView {
    id: Uuid,
    name: String,
    #[view(to_one(fk = "assignee_id"))]
    assignee: Option<PersonView>,                 // one batched query for every task's assignee
    #[view(child(fk = "parent_id", order_by = "position"))]
    children: Vec<SubtaskView>,                   // one batched query for every task's subtasks
}

let tasks = mabat::load::<TaskView>().filter(col("status").eq("open")).all(&mut conn).await?;

Typed views, not entities

Structs, enums with data, embedded values, ordered lists, maps, many-to-many collections, recursive trees and cyclic graphs — declared with one derive, decoded strictly, with errors that name the path.

Tunable SQL, checked at startup

Replace any query with hand-written SQL in an override file. Every query is prepared against the database at startup and compared with the view, and a shadow mode proves a tuned query equivalent before you rely on it.

JSON and GraphQL

Load only the fields a client selects, as JSON, or serve a GraphQL schema generated from the views — each request one planned load, with filters and paging at every level.

Aggregates in, aggregates out

Save a value and everything it owns, save only what changed between two versions, and lock rows optimistically with a version column.

Three databases

PostgreSQL, MySQL 8 and SQLite through SQLx, with concurrent loads on a pool and a shared snapshot on PostgreSQL.

A specification you can cite

MPA, the Mabat Persistence Architecture, states every behaviour as a numbered rule — for code reviews, issues and AI assistants alike.