Skip to content

Store Refactor #2986

@mossid

Description

@mossid

The store/ is quite large and the parts are deeply interconnected with each other, so refactoring will be split into three parts:

1. Move store types to separate folders #2309

Each store type, such as rootmultistore.go, iavlstore.go, will be moved into separated folders, for example, rootmulti/store.go, iavl/store.go. Actual types will be named Store, making them exposed and easily accessible from external code - the caller can use iavl.Store for example.

We cannot use KVStore.Gas() and KVStore.Prefix() now, since it causes import cycle between store/prefix and store/gas. For now we remove those methods and use gas.NewStore and prefix.NewStore directly.

The dependency of store on types will be inverted, meaning that types/store.go, types/gas.go, types/queryable.go and part of types/errors.go will be moved to store/types/, and types/store.go will reexport them. But in the first PR, only types/store.go and types/gas.go will be moved.

WIP on #2985

2. Invert dependency

Because some of the error types are used by both store/* and the outside, we have to duplicate the error types from types/ to store/types/. This PR will move types/errors.go and types/queryable.go to store/types/.

3. Simplify store interfaces

Currently the interfaces in types/store.go have multiple layers of embedding which is hard to analyze. The second PR will simplify it to two-layer structure.

            KVStore         CommitStore          MultiStore              ^
           /        \         /        \           /       \             |
         /            \     /            \       /          \            |  embeds
CacheKVStore    CommitKVStore    CommitMultiStore    CacheMultiStore     *

It will also contain #2824. (Should it also be applied on gas?)

Also, instead of using StoreType, which is an enum type rootmulti.Store switches internally, we associate the StoreKey and KVStore/MultiStore implementation so the multistore can also mount third-party store type (needs discussion).

StoreKey will be split into KVStoreKey and MultiStoreKey, making it typesafe when accessing on substores and to prepare on future recursive multistore implementation.

The primitive version can be found in #2344

Metadata

Metadata

Assignees

Labels

Type: Code HygieneGeneral cleanup and restructuring of code to provide clarity, flexibility, and modularity.

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions