pub trait Transaction: ReadTransaction {
Show 15 methods fn add_read_conflict_key(&self, key: impl Into<Key>) -> FdbResult<()>; fn add_read_conflict_range(&self, range: Range) -> FdbResult<()>; fn add_write_conflict_key(&self, key: impl Into<Key>) -> FdbResult<()>; fn add_write_conflict_range(&self, range: Range) -> FdbResult<()>; unsafe fn cancel(&self); fn clear(&self, key: impl Into<Key>); fn clear_range(&self, range: Range); unsafe fn commit(&self) -> FdbFutureUnit; fn get_approximate_size(&self) -> FdbFutureI64; unsafe fn get_committed_version(&self) -> CommittedVersion; unsafe fn get_versionstamp(&self) -> TransactionVersionstamp; unsafe fn mutate(
        &self,
        optype: MutationType,
        key: impl Into<Key>,
        param: Bytes
    ); unsafe fn reset(&self); fn set(&self, key: impl Into<Key>, value: impl Into<Value>); fn watch(&self, key: impl Into<Key>) -> FdbFutureUnit;
}
Expand description

A Transaction represents a FDB database transaction.

All operations on FDB take place, explicity or implicity, through a Transaction.

In FDB, a transaction is a mutable snapshot of a database. All read and write operations on a transaction see and modify an otherwise-unchanging version of the database and only change the underlying database if and when the transaction is committed. Read operations do see the effects of previous write operations on the same transactions. Committing a transaction usually succeeds in the absence of conflicts.

Transactions group operations into a unit with the properties of atomicity, isolation, and durability. Transactions also provide the ability to maintain an application’s invariants or integrity constraints, supporting the property of consistency. Together these properties are known as ACID.

Transactions are also causally consistent: once a transaction has been successfully committed, all subsequently created transactions will see the modifications made by it. The most convenient way for a developer to manage the lifecycle and retrying of a transaction is to use run method on FdbDatabase. Otherwise, the client must have retry logic for fatal failures, failures to commit, and other transient errors.

Keys and values in FDB are byte arrays. To encode other data types, see the tuple layer documentation.

Note: All keys with first byte 0xff are reserved for internal use.

Required Methods

Adds a key to the transaction’s read conflict ranges as if you had read the key.

Adds a range of keys to the transaction’s read conflict ranges as if you had read the range.

Adds a key to the transaction’s write conflict ranges as if you had written the key.

Adds a range of keys to the transaction’s write conflict ranges as if you had cleared the range.

Cancels the Transaction.

Safety

See C API for more details.

Clears a given key from the database.

Clears a range of keys from the database.

Commit this Transaction.

Equivalent to:

async unsafe fn commit(&self) -> FdbResult<()>
Safety

See C API for more details.

Returns a future that will contain the approximated size of the commit, which is the summation of mutations, read conflict ranges, and write conflict ranges.

async fn get_approximate_size(&self) -> FdbResult<i64>

Gets the version number at which a successful commit modified the database.

Safety

See C API for more details.

Returns TransactionVersionstamp from which you can get the versionstamp which was used by any versionstamp operations in this transaction.

Safety

See C API for more details.

An atomic operation is a single database command that carries out several logical steps: reading the value of a key, performing a transformation on that value, and writing the result.

Safety

See the warning for MutationType::AppendIfFits variant.

Reset the Transaction.

Safety

See C API for more details.

Sets the value for a given key.

Creates a watch that will become ready when it reports a change to the value of the specified key.

A watch’s behavior is relative to the transaction that created it.

Implementors