Choose bounds for the workload
Construct Database_Limits and each Column_Family_Configuration before you create the database.
Set transaction, mutation, key, value, batch, history, family, run, read-set, scan-range, task, and byte limits from the application workload. Flyology.DB persists the limits and checks later allocations and decoded objects against them.
Example values are fixtures. They are not defaults or recommendations.
Persist every durable identity allocator
Never reuse an ID after its operation can enter publication. This rule applies even when the caller sees a timeout, cancellation, or unknown outcome.
Keep durable allocators for database IDs, transaction IDs, batch IDs when distinct, manifests, runs, metadata transitions, and family IDs. Commit groups retain distinct transaction-member identities even when they share one batch.
Bind one caller-owned provider
Use the local Files backend for a retained-root development walkthrough. For S3-compatible storage, supply a caller-owned authenticated client, bucket, prefix, endpoint, credentials, timeout, and provider policy.
Flyology.DB does not choose transport retries, endpoint behavior, credential refresh, requester-pays policy, or cloud retention. Object storage remains the authority for acknowledged durable state.
Keep borrowed owners alive
The database borrows its storage binding. The binding borrows the provider backend or authenticated client. Keep that complete owner chain alive until every database, transaction, family handle, and operation that uses it has finished.
Close or roll back child owners before Close. After a reopen or family-registry change, obtain fresh handles from the current database owner.
Choose synchronous or composable calls
The synchronous calls are convenience waits over the same state machines used by caller-composable operations. Both forms use the same deadlines, receipts, certainty rules, and publication identities.
Composable calls use caller-owned completion sets and unique buffers. Finish every admitted operation to restore moved tokens and classify its result.
Refresh a caller-designated read-only replica
The application can trigger a monotonic replica refresh. Refresh validates one complete recovery graph and installs it only when its transition and writer epoch are newer.
The library does not register replicas, poll, lease, coordinate retention, or promote a replica to writer. A fenced handle remains fenced.