Skip to content

Implement more testing for db/stores #23

@paulhauner

Description

@paulhauner

There are some basic implementations of "stores" here:

https://github.com/sigp/lighthouse/tree/master/lighthouse/db/stores

The goal of the stores concept is to abstract database operations away from "higher-level" parts of the application. Each store is initialized with some underlying database implementing the ClientDB trait. The store provides read/write access to specific parts of the database. Stores are separated by topic (e.g., blocks, validations) for two main reasons (a) it's nice to separate things and have smaller files and, (b) having separate stores helps to communicate which parts of the database some function might access to.

In the near future, stores may implementing caching, bloom filters and other whiz-bang things to speed up data access.

The ClientDB trait has a concept of "columns" to help separate the key space between stores. It's up to the underlying database as to how it implements these columns. MemoryDB just adds a prefix to each key in order to separate columns. DiskDB (RocksDB) might choose to implement some columns as actual RocksDB columns and others as just prefixes in the same physical column.

Presently, the tests for the stores are pretty dismal. It would be great to have some tests comprehensive tests. We only need to test against MemoryDB, using DiskDB is cumbersome and the two should always perform identically -- if they don't it's an issue for the databases ClientDB implementation.

Happy to assist anyone who wants to work on this :)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions