-
Notifications
You must be signed in to change notification settings - Fork 782
feat: added in memory implementation of blockdb #4212
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
base: master
Are you sure you want to change the base?
Conversation
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.
Pull Request Overview
This PR introduces an in-memory implementation of the BlockDatabase interface for testing purposes, allowing tests to avoid using on-disk storage when not necessary.
- Adds a new
MemoryDatabase
struct that implements theBlockDatabase
interface - Provides thread-safe operations using read-write mutexes
- Includes proper error handling for closed database states and empty blocks
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
x/blockdb/memory_db.go
Outdated
} | ||
|
||
// WriteBlock stores a block in memory | ||
func (m *MemoryDatabase) WriteBlock(height BlockHeight, block BlockData) error { |
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.
blockData is a slice so why do we copy it and not just save the reference? This is for tests. Do we expect the original slice to be changed?
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.
i don't expect it to be changed in tests but it definitely could, which might cause confusion when debugging.
I opted to copy it since that mirrors the block database behaviour.
x/blockdb/memory_db.go
Outdated
defer m.mu.Unlock() | ||
|
||
m.closed = true | ||
m.blocks = nil |
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.
random comment: I guess we don't technically have to clear out this db since all future operations are stopped and this operation is idempotent - but I don't think we care either way... so feel free to ignore this...
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.
setting to nil does allow the blocks to be garbage collected in case the db reference is still around.
Why this should be merged
For tests where we don't need to use on an on-disk block store, we can use this
blockdb.MemoryDatabase
.For example, #4208 uses this MemoryDatabase to test the
meterblockdb
How this works
Use
blockdb.MemoryDatabase
to create a block database that implementsdatabase.BlockDatabase
. It writes and reads blocks from memory.How this was tested
Tests that uses the MemoryDatabase. Currently just in #4208
Need to be documented in RELEASES.md?
No