-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Approval voting overlay db #3366
Changes from 6 commits
55afad7
a7a612a
5bf68b0
844e56b
3e9e5f3
12899aa
7b9ff0d
46df410
103b873
7ae0dfa
ef68ae1
ffabf96
6b0f048
4e8dde8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,289 @@ | ||||||
| use kvdb::{DBTransaction, KeyValueDB}; | ||||||
| use polkadot_node_subsystem::{SubsystemResult}; | ||||||
| use polkadot_primitives::v1::{BlockNumber, CandidateHash, Hash}; | ||||||
| use parity_scale_codec::{Encode}; | ||||||
|
|
||||||
| use std::collections::HashMap; | ||||||
| use std::sync::Arc; | ||||||
|
|
||||||
| use super::approval_db; | ||||||
| use super::approval_db::v1::{ | ||||||
| blocks_at_height_key, block_entry_key, candidate_entry_key, STORED_BLOCKS_KEY, Config, | ||||||
| }; | ||||||
| use super::ops::StoredBlockRange; | ||||||
| use super::persisted_entries::{BlockEntry, CandidateEntry}; | ||||||
|
|
||||||
| #[derive(Debug)] | ||||||
| pub(super) enum BackendWriteOp { | ||||||
| WriteStoredBlockRange(StoredBlockRange), | ||||||
| WriteBlocksAtHeight(BlockNumber, Vec<Hash>), | ||||||
| WriteBlockEntry(BlockEntry), | ||||||
| WriteCandidateEntry(CandidateEntry), | ||||||
| DeleteBlocksAtHeight(BlockNumber), | ||||||
| DeleteBlockEntry(Hash), | ||||||
| DeleteCandidateEntry(CandidateHash), | ||||||
| } | ||||||
|
|
||||||
| pub(super) struct DbBackend { | ||||||
rphmeier marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| inner: Arc<dyn KeyValueDB>, | ||||||
| pub(super) config: Config, | ||||||
|
||||||
| } | ||||||
|
|
||||||
| impl DbBackend { | ||||||
| /// Create a new [`DbBackend`] with the supplied key-value store and | ||||||
| /// config. | ||||||
| pub fn new(db: Arc<dyn KeyValueDB>, config: Config) -> Self { | ||||||
| DbBackend { | ||||||
| inner: db, | ||||||
| config, | ||||||
| } | ||||||
| } | ||||||
| } | ||||||
|
|
||||||
|
||||||
| use super::ops; |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| super::ops::load_candidate_entry(&*self.inner, &self.config, candidate_hash) | |
| ops::load_candidate_entry(&*self.inner, &self.config, candidate_hash) |
ordian marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok(()) here is redundant if the ?; is omitted from the above line, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference is the current impl does an implicit type conversion, if the returned Error types are the same, it indeed can be omitted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a fan of this implicit encoding set with Options, could we not store BackendWriteOp directly? It costs a few extra bytes for the hash being present in addition, but from a clarity pov this would be advantageous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's actually a great suggestion... I would suggest we merge this PR and then follow-up in an additional PR, but more than happy to explore the right approach in this PR.
Paging @rphmeier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So basically, instead of a HashMap<K, Option<V>>, you are suggesting we use
HashMap<K, BackendWriteOp> ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would the idea there be to have a single map K -> BackendWriteOp? Otherwise I think it could get less clear, not more, because the type system would then express the possibility to have a BackendWriteOp::WriteCandidateEntry in the block_entries map, for example.
Reusing Option for this is a little semantically wrong, but maybe a new enum is a better solution:
enum OverlayValue<T> { Present(T), Deleted }
// Semantically - `None` means 'defer to underlying'
stored_block_range: Option<OverlayValue<StoredBlockRange>>,
// Same here, when calling 'get' for a particular `Hash`.
block_entries: HashMap<Hash, OverlayValue<BlockEntry>>,
Uh oh!
There was an error while loading. Please reload this page.