Struct Capabilities 

pub struct Capabilities {
    pub atomic_replace: bool,
    pub exclusive_create: bool,
    pub sync_guarantee: SyncGuarantee,
    pub native_transactions: bool,
}

The durability guarantees a Storage backend can make — declared by the backend through Storage::capabilities, honored by the crash-safety machinery in ChangeSet.

The point of naming these explicitly is that a transaction must run correctly over backends that keep very different promises. Rather than assume a guarantee and corrupt data on the backend that cannot keep it, the apply path reads the capabilities and picks the strongest protocol the backend actually supports: a filesystem gets atomic-rename writes and a journal; a transactional store is handed the whole change set to commit itself; a backend that can promise neither still works, it simply cannot claim a write survives a crash.

Fields

atomic_replace: bool

The backend can replace an existing file’s contents in one indivisible step, so no crash exposes a half-written file — an observer sees the whole old contents or the whole new. On a filesystem this is realized by Storage::write_atomic’s write-temp-then-rename; a backend may instead be atomic by nature.

exclusive_create: bool

The backend can create a file only if nothing is at its path yet, as one operation — Storage::create_new. The create and the test-for-existence cannot be split: two writers racing to the same name see exactly one succeed and the other told AlreadyExists, with no window between the test and the create for a half-written file to slip through. This is the primitive an append-only, write-once consumer builds its whole concurrency story on, which is why it is declared rather than emulated: a check-then-write emulation has the window in it, and a backend that cannot close the window must say so instead of pretending.

sync_guarantee: SyncGuarantee

How strong the backend’s Storage::sync is: whether it can flush at all, and if so whether a flush merely orders writes or carries them through a power cut. fsync on std::fs, FileSystemSyncAccessHandle .flush() on OPFS, the implicit durability of a committed IndexedDB transaction.

native_transactions: bool

The backend commits changes to many objects as one indivisible unit, so this crate’s write-ahead journal would be redundant and a caller should defer to the backend instead. True for IndexedDB; false for a plain filesystem, where multi-file atomicity is the journal’s job to provide.

Implementations

impl Capabilities

pub const NONE: Capabilities

Promises nothing — the safe assumption for an unknown backend, and the Storage::capabilities default. Every field is the pessimistic value, so code that checks a capability before relying on it takes the most defensive branch unless a backend has explicitly earned a lighter one.

pub const LOCAL_FS: Capabilities

A conventional local filesystem: atomic replacement by rename, exclusive create (O_CREAT|O_EXCL, honored by every OS this crate targets), and durable fsync — but no native multi-object transaction (that is the journal’s job). What StdFs reports on every platform this crate targets.

pub const IN_MEMORY: Capabilities

An in-process, memory-only store (InMemoryFs): every mutation takes the backend’s single lock for its whole duration, so one write already swaps old bytes for new as one indivisible step — no separate temp-then-rename dance is needed for atomic_replace to be true. But nothing here is backed by anything other than process memory, so its sync_guarantee is SyncGuarantee::None: there is nothing to flush, and the entire store evaporates the instant the process exits — it cannot even promise ordering against a crash it will not survive. native_transactions is false too — the lock makes each single call atomic, not a batch of several calls committed together, so a multi-file change set still needs the write-ahead journal over this backend exactly as it would over a real filesystem. exclusive_create is true on the same grounds as atomic_replace: one locked call checks and inserts without anything interleaving.

Trait Implementations

impl Clone for Capabilities

fn clone(&self) -> Capabilities

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for Capabilities

impl Debug for Capabilities

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl Eq for Capabilities

impl PartialEq for Capabilities

fn eq(&self, other: &Capabilities) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for Capabilities