Add one immutable family configuration
The Flyology.DB family append requires a retained durable checkpoint. A fresh database without a checkpoint returns Invalid_State.
Supply a family ID that is higher than every installed family ID. Supply a unique name, complete Column_Family_Configuration, fresh manifest ID, fresh transition ID, and one deadline. The example supplies those values through Audit_Family_Configuration and IDs 11 and 12.
DB.Add_Column_Family
(Item,
Audit_Family_Configuration,
Family_Manifest_ID,
Family_Transition_ID,
Timeout,
Receipt => Family_Info,
Result => Result);
if Result = DB.Outcome_Unknown then
DB.Resolve_Add_Column_Family
(Item, Family_Info, Timeout, Result => Result);
end if;
Expect
(Result, DB.Success, "family append did not resolve conclusively");If the result is Outcome_Unknown, call Resolve_Add_Column_Family with the same receipt. Do not submit the append under replacement identities.
Open a fresh family handle
After the append succeeds, open the new family by ID or name. Do not reuse a family handle from before the registry changed.
A transaction can now write to the old and new families. Both families share the same database-wide commit sequence and transaction log.
Flush every changed family in one boundary
Map each family that needs a snapshot to one fresh run ID. The example maps family 1 to Suffix_Run_ID and family 2 to Audit_Run_ID through Extended_Runs.
DB.Flush
(Item,
Extended_Runs,
Second_Flush_Manifest_ID,
Second_Flush_Transition_ID,
Timeout,
Receipt => Flush_Info,
Result => Result);
if Result = DB.Outcome_Unknown then
DB.Resolve_Flush (Item, Flush_Info, Timeout, Result => Result);
end if;
Expect
(Result, DB.Success, "two-family Flush did not resolve conclusively");A changed family gets a new suffix-delta run. An empty or unchanged family consumes no new run object or identity. Flush publishes one successor manifest and one metadata transition for the complete checkpoint boundary. It does not select a schedule, retry policy, or deletion policy.
Compact an exact current view
Choose one of the current public compaction shapes:
- replace the complete live state with one fresh run per nonempty family;
- replace two adjacent runs with one fresh run; or
- replace three consecutive runs with one fresh run.
Supply every selected run and every new publication identity. All forms retain predecessor objects and any later commit suffix. The adjacent-run forms also retain every version, tombstone, and surrounding run.
Keep unsupported mutation out of the plan
The current API can append a family. It cannot rename, drop, reorder, or reconfigure an installed family.
The library also provides no automatic compaction, retention horizon, pruning, deletion, or garbage-collection service. The application owns those decisions.
Handle uncertainty before retry logic
Family append and Flush use receipts, but durable cross-process authority currently applies only to Commit. The next chapter explains the exact Commit boundary.