This repository was archived by the owner on Nov 15, 2023. It is now read-only.
Typed chain state queries over rpc. #4059
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…clared by 'decl_storage!'.
…titive. This commit makes the implementation simpler by intruducing a struct which represents query for a typed value in storage. The new struct is called StorageQuery. A StorageQuery wraps a raw StorageKey but is not directy constructable. To construct a StorageQuery, the user must supply an implementation of a srml_support::storage::generator trait such as StorageValue or StorageMap. A type implementing one of the generator traits can be aquired by: A) marking a storage item as pub within a call to decl_storage (recommended) or B) implementing one of the generator types manually. While option B may sometimes me necessary, it's not recommended because separate manual implementaions may lose sync with the original definition.
declaration. This field was added to support a test in an earlier commit. The test no longer relies on test-runtime so the change can be reverted.
|
It looks like @bddap signed our Contributor License Agreement. 👍 Many thanks, Parity Technologies CLA Bot |
tomusdrw
reviewed
Nov 9, 2019
Contributor
tomusdrw
left a comment
tomusdrw
left a comment
There was a problem hiding this comment.
Looks good!
The core RPC does not depend on (or assume the existence of) srml, and I suppose we want to keep it this way.
I think the RPC should be rather moved to srml and be treated as opt-in core-RPC extension (see how we initialize srml-system-rpc for instance).
| [package] | ||
| name = "substrate-rpc-custom" | ||
| version = "0.1.0" | ||
| authors = ["Andrew Dirksen <[email protected]>"] |
Contributor
There was a problem hiding this comment.
Should include ParityTech I suppose?
Contributor
|
@tomusdrw let's merge and resolve the dependency in the upcoming re-org?!? |
Contributor
|
Superseded by #4079 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pr adds the ability to query values from chain state in a type-safe way, over rpc.
The decl_storage macro already generates implementations of the srml_support::storage::generator traits (StorageValue, StorageMap, StorageLinkedMap, and StorageDoubleMap). Those traits are currently used to provide type-safe storage access to runtime modules. This pr uses those same traits to provide type-safe storage access over json rpc. The approach keeps users from manually calculating storage keys, a potentially error prone process.
This pr adds minimal functionality, just the ability to get a typed value using a typed key. If the changes are well received, I'd like to look into additional functionality, like subscribing to typed keys, subscribing to events, creating and submitting typed extrinsics, etc.
The new workspace member is called substrate-rpc-custom as it allows queries on storage defined custom runtime modules, as opposed to substrate-rpc-api, which is mostly runtime agnostic. The new workspace member depends on both srml-support and on substrate-rpc-api. It was placed in "core/rpc/custom", alongside other rpc utilities, for discoverability.