Expand description
The reconcile planner: a pure function from (desired, live) table state to
a ReconcilePlan — a value describing exactly what a backend must do to
bring the target in line with the incoming RecordBatch schema and contract.
This is the describe half of describe-vs-execute (ADR-0062 / the Zerobus
sink plan §5.1): the plan is computed here, logged, and unit-tested without
a live catalog; a crate::TableCatalog backend then executes it.
Policy (identical to the sink-blueprint schema-evolution rule):
- create-on-absent — no live table ⇒ one
CreateTable. - additive is safe — a new column ⇒
AddColumn(+ its comment). - widening is conditionally safe — a live column whose type can widen to
the desired type ⇒
WidenColumn, but only when widening is enabled; else aRefusal. - anything else fails loud — narrowing, an incompatible type change, and
(optionally) a dropped column become
Refusals, never silent data loss. - comments re-sync idempotently — a managed comment is (re)stamped only when its content hash differs from what the backend last synced.
Structs§
- Reconcile
Options - Options controlling how strict the planner is.
- Reconcile
Plan - The full plan: an ordered list of steps plus any refusals.
- Refusal
- A refusal: a change the planner will not perform, with a human-readable reason. A plan with any refusal must fail loud — never silently degrade.
Enums§
- Comment
Target - Where a comment is applied.
- Plan
Step - A single action a backend must take to reconcile the target.
Functions§
- plan
- Compute the plan to reconcile
desiredagainstcurrent(the live table, orNoneif it does not exist yet).