-
Notifications
You must be signed in to change notification settings - Fork 742
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement more testing for db/stores #23
Labels
Comments
@g-r-a-n-t is working on this. |
Merged
Completed! |
divagant-martian
pushed a commit
to divagant-martian/lighthouse
that referenced
this issue
Nov 21, 2022
make it compile to start from here
mergify bot
pushed a commit
that referenced
this issue
Apr 22, 2024
* by-root-stream-terminator * Fix tests * Resolve merge conflicts * Log report reason * Some lints and bugfixes (#23) * fix lints * bug fixes * Fix tests * Merge branch 'unstable' of https://github.com/sigp/lighthouse into handle-sync-lookup-requests * Pr 5583 review (#24) * add bad state warn log * add rust docs to new fields in `SyncNetworkContext` * remove timestamp todo * add back lookup verify error * remove TODOs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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 theClientDB
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 :)
The text was updated successfully, but these errors were encountered: