View Source API Reference fdbc v0.1.4

An unofficial FoundationDB client for Elixir.

An FDBC.Database represents a FoundationDB database — a mutable, lexicographically ordered mapping from binary keys to binary values. Modifications to a database are performed via transactions.

FoundationDB provides the directories layer as a tool for managing related subspaces. Directories are a recommended approach for administering applications. Each application should create or open at least one directory to manage its subspaces.

An exception raised when an error is returned from a call to the FDBC NIF.

A convenience behaviour to ease the use of a database instance within an OTP application while also promoting best practices.

Most functions in the FoundationDB API are asynchronous, meaning that they may return to the caller before actually delivering their result. An FDBC.Future object represents a result value or error to be delivered at some future time. A future can be awaited on or periodically checked to see if it is ready. Once a Future is ready it can be resolved to get its underlying value, which is dependant on the function that created the future.

FoundationDB’s lexicographically ordered data model permits finding keys based on their order (for example, finding the first key in the database greater than a given key). Key selectors represent a description of a key in the database that could be resolved to an actual key by FDBC.Transaction.get_key/3 or used directly as the beginning or end of a range in FDBC.Transaction.get_range/4.

A module used to start and stop the network thread which is responsible for running most of the clients tasks.

Subspaces provide the recommended way to define namespaces for different categories of data. As a best practice, you should always use at least one subspace as a namespace for your application data.

Represents a FoundationDB tenant. Tenants are optional named transaction domains that can be used to provide multiple disjoint key-spaces to client applications. A transaction created in a tenant will be limited to the keys contained within that tenant, and transactions operating on different tenants can use the same key names without interfering with each other.

In FoundationDB, 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 transaction. Committing a transaction usually succeeds in the absence of conflicts.

An implementation of upstreams builtin tuple layer. This layer is used for encoding keys that are useable by FoundationDB. The encoded key maintains the same sort order as the original tuple: sorted first by the first element, then by the second element, etc. This makes the tuple layer ideal for building a variety of higher-level data models.

A behaviour module for implementing user type codes.

Used to represent values written by versionstamp operations within the tuple layer. This wraps a binary of length 12 that can be used to represent some global order of items within the database.