fix(server/v2/cometbft): fix mock store (#22293)

server/v2/cometbft/internal/mock/mock_store.go

@@ -16,11 +16,11 @@ import (
 )
 
 type MockStore struct {
-	Storage   storev2.VersionedDatabase
+	Storage   storev2.VersionedWriter
 	Committer storev2.Committer
 }
 
-func NewMockStorage(logger log.Logger, dir string) storev2.VersionedDatabase {
+func NewMockStorage(logger log.Logger, dir string) storev2.VersionedWriter {
 	storageDB, _ := sqlite.New(dir)
 	ss := storage.NewStorageStore(storageDB, logger)
 	return ss
@@ -36,7 +36,7 @@ func NewMockCommiter(logger log.Logger, actors ...string) storev2.Committer {
 	return sc
 }
 
-func NewMockStore(ss storev2.VersionedDatabase, sc storev2.Committer) *MockStore {
+func NewMockStore(ss storev2.VersionedWriter, sc storev2.Committer) *MockStore {
 	return &MockStore{Storage: ss, Committer: sc}
 }
 
@@ -83,7 +83,7 @@ func (s *MockStore) StateAt(version uint64) (corestore.ReaderMap, error) {
 	return NewMockReaderMap(version, s), nil
 }
 
-func (s *MockStore) GetStateStorage() storev2.VersionedDatabase {
+func (s *MockStore) GetStateStorage() storev2.VersionedWriter {
 	return s.Storage
 }
 

store/v2/mock/types.go

@@ -10,7 +10,7 @@ type StateCommitter interface {
 	store.UpgradeableStore
 }
 
-// StateStorage is a mock of store.VersionedDatabase
+// StateStorage is a mock of store.VersionedWriter
 type StateStorage interface {
 	store.VersionedWriter
 	store.UpgradableDatabase

store/v2/storage/README.md

@@ -2,7 +2,7 @@
 
 The `storage` package contains the state storage (SS) implementation. Specifically,
 it contains RocksDB, PebbleDB, and SQLite (Btree) backend implementations of the
-`VersionedDatabase` interface.
+`VersionedWriter` interface.
 
 The goal of SS is to provide a modular storage backend, i.e. multiple implementations,
 to facilitate storing versioned raw key/value pairs in a fast embedded database,
@@ -26,7 +26,7 @@ latest and historical versions efficiently.
 ### RocksDB
 
 The RocksDB implementation is a CGO-based SS implementation. It fully supports
-the `VersionedDatabase` API and is arguably the most efficient implementation. It
+the `VersionedWriter` API and is arguably the most efficient implementation. It
 also supports versioning out-of-the-box using User-defined Timestamps in
 ColumnFamilies (CF). However, it requires the CGO dependency which can complicate
 an app’s build process.
@@ -42,7 +42,7 @@ and does not require CGO.
 ### SQLite (Btree)
 
 The SQLite implementation is another CGO-based SS implementation. It fully supports
-the `VersionedDatabase` API. The implementation is relatively straightforward and
+the `VersionedWriter` API. The implementation is relatively straightforward and
 easy to understand as it’s entirely SQL-based. However, benchmarks show that this
 options is least performant, even for reads. This SS backend has a lot of promise,
 but needs more benchmarking and potential SQL optimizations, like dedicated tables
@@ -92,7 +92,7 @@ batch object which is committed to the underlying SS engine.
 
 An SS backend is meant to be used within a broader store implementation, as it
 only stores data for direct and historical query purposes. We define a `Database`
-interface in the `storage` package which is mean to be represent a `VersionedDatabase`
+interface in the `storage` package which is mean to be represent a `VersionedWriter`
 with only the necessary methods. The `StorageStore` interface is meant to wrap or
 accept this `Database` type, e.g. RocksDB.
 

store/v2/storage/store.go

@@ -22,7 +22,7 @@ var (
 	_ store.UpgradableDatabase     = (*StorageStore)(nil)
 )
 
-// StorageStore is a wrapper around the store.VersionedDatabase interface.
+// StorageStore is a wrapper around the store.VersionedWriter interface.
 type StorageStore struct {
 	logger log.Logger
 	db     Database