Crate reth_db_api

Source
Expand description

reth’s database abstraction layer.

The database abstraction assumes that the underlying store is a KV store subdivided into tables.

One or more changes are tied to a transaction that is atomically committed to the data store at the same time. Strong consistency in what data is written and when is important for reth, so it is not possible to write data to the database outside of using a transaction.

Good starting points for this crate are:

§Cursors and Walkers

The abstraction also defines a couple of helpful abstractions for iterating and writing data:

  • Cursors (DbCursorRO / DbCursorRW) for iterating data in a table. Cursors are assumed to resolve data in a sorted manner when iterating from start to finish, and it is safe to assume that they are efficient at doing so.
  • Walkers (Walker / RangeWalker / ReverseWalker) use cursors to walk the entries in a table, either fully from a specific point, or over a range.

Dup tables (see below) also have corresponding cursors and walkers (e.g. DbDupCursorRO). These should be preferred when working with dup tables, as they provide additional methods that are optimized for dup tables.

§Tables

reth has two types of tables: simple KV stores (one key, one value) and dup tables (one key, many values). Dup tables can be efficient for certain types of data.

Keys are de/serialized using the Encode and Decode traits, and values are de/serialized (“compressed”) using the Compress and Decompress traits.

Tables implement the Table trait.

Re-exports§

Modules§

Macros§

Enums§

Traits§