mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-11 15:21:08 +00:00
d7124b56f7
* WIP backend trait * WIP converting higher level stuff to using Backend impl * more implementing new backend trait, mainly storage focused * Get core code compiling with new backend bits * subxt crate checks passing * fix tests * cargo fmt * clippy/fixes * merging and other fixes * fix test * fix lightclient code * Fix some broken doc links * another book link fix * fix broken test when moving default_rpc_client * fix dry_run test * fix more tests; lightclient and wasm * fix wasm tests * fix some doc examples * use next() instead of next_item() * missing next_item() -> next()s * move legacy RPc methods to LegacyRpcMethods type to host generic param instead of RpcClient * standardise on all RpcClient types prefixed with Rpc, and 'raw' trait types prefixed with RawRpc so it's less ocnfusing which is which * rename fixes * doc fixes * Add back system_dryRun RPC method and rename tx.dry_run() to tx.validate(), to signal that the calls are different * Add a test that we return the correct extrinsic hash from submit() * add TransactionValid details back, and protect against out of range bytes * add test for decoding transaction validation from empty bytes * fix clippy warning
131 lines
5.8 KiB
Rust
131 lines
5.8 KiB
Rust
// Copyright 2019-2023 Parity Technologies (UK) Ltd.
|
|
// This file is dual-licensed as Apache-2.0 or GPL-3.0.
|
|
// see LICENSE for license details.
|
|
|
|
//! # Storage
|
|
//!
|
|
//! A Substrate based chain can be seen as a key/value database which starts off at some initial
|
|
//! state, and is modified by the extrinsics in each block. This database is referred to as the
|
|
//! node storage. With Subxt, you can query this key/value storage with the following steps:
|
|
//!
|
|
//! 1. [Constructing a storage query](#constructing-a-storage-query).
|
|
//! 2. [Submitting the query to get back the associated values](#submitting-it).
|
|
//!
|
|
//! ## Constructing a storage query
|
|
//!
|
|
//! We can use the statically generated interface to build storage queries:
|
|
//!
|
|
//! ```rust,no_run
|
|
//! use subxt_signer::sr25519::dev;
|
|
//!
|
|
//! #[subxt::subxt(runtime_metadata_path = "../artifacts/polkadot_metadata_small.scale")]
|
|
//! pub mod polkadot {}
|
|
//!
|
|
//! let account = dev::alice().public_key().into();
|
|
//! let storage_query = polkadot::storage().system().account(&account);
|
|
//! ```
|
|
//!
|
|
//! Alternately, we can dynamically construct a storage query. This will not be type checked or
|
|
//! validated until it's submitted:
|
|
//!
|
|
//! ```rust,no_run
|
|
//! use subxt_signer::sr25519::dev;
|
|
//! use subxt::dynamic::Value;
|
|
//!
|
|
//! let account = dev::alice().public_key();
|
|
//! let storage_query = subxt::dynamic::storage("System", "Account", vec![
|
|
//! Value::from_bytes(account)
|
|
//! ]);
|
|
//! ```
|
|
//!
|
|
//! As well as accessing specific entries, some storage locations can also be iterated over (such as
|
|
//! the map of account information). To do this, suffix `_iter` onto the query constructor (this
|
|
//! will only be available on static constructors when iteration is actually possible):
|
|
//!
|
|
//! ```rust,no_run
|
|
//! #[subxt::subxt(runtime_metadata_path = "../artifacts/polkadot_metadata_small.scale")]
|
|
//! pub mod polkadot {}
|
|
//!
|
|
//! // A static query capable of iterating over accounts:
|
|
//! let storage_query = polkadot::storage().system().account_iter();
|
|
//! // A dynamic query to do the same:
|
|
//! let storage_query = subxt::dynamic::storage("System", "Account", Vec::<u8>::new());
|
|
//! ```
|
|
//!
|
|
//! Some storage entries are maps with multiple keys. As an example, we might end up with
|
|
//! an API like `runtime::storage().foo().bar(u8, bool, u16, String)` to fetch some entry "bar".
|
|
//! When this is the case, the codegen will generate multiple iterator query functions alongside
|
|
//! the function to fetch an individual value:
|
|
//!
|
|
//! - `runtime::storage().foo().bar(u8, bool, u16, String)`: fetch a single entry from the "bar" map.
|
|
//! - `runtime::storage().foo().bar_iter()`: iterate over all of the entries in the "bar" map.
|
|
//! - `runtime::storage().foo().bar_iter1(u8)`: iterate over all of the entries in the "bar" map under
|
|
//! a given `u8`.
|
|
//! - `runtime::storage().foo().bar_iter2(u8, bool)`: iterate over all of the entries in the "bar" map under
|
|
//! a given `u8` and `bool` value.
|
|
//! - `runtime::storage().foo().bar_iter3(u8, bool, u16)`: iterate over all of the entries in the "bar" map under
|
|
//! a given `u8`, `bool` and `u16` value.
|
|
//!
|
|
//! All valid storage queries implement [`crate::storage::StorageAddress`]. As well as describing
|
|
//! how to build a valid storage query, this trait also has some associated types that determine the
|
|
//! shape of the result you'll get back, and determine what you can do with it (ie, can you iterate
|
|
//! over storage entries using it).
|
|
//!
|
|
//! Static queries set appropriate values for these associated types, and can therefore only be used
|
|
//! where it makes sense. Dynamic queries don't know any better and can be used in more places, but
|
|
//! may fail at runtime instead if they are invalid in those places.
|
|
//!
|
|
//! ## Submitting it
|
|
//!
|
|
//! Storage queries can be handed to various functions in [`crate::storage::Storage`] in order to
|
|
//! obtain the associated values (also referred to as storage entries) back.
|
|
//!
|
|
//! ### Fetching storage entries
|
|
//!
|
|
//! The simplest way to access storage entries is to construct a query and then call either
|
|
//! [`crate::storage::Storage::fetch()`] or [`crate::storage::Storage::fetch_or_default()`] (the
|
|
//! latter will only work for storage queries that have a default value when empty):
|
|
//!
|
|
//! ```rust,ignore
|
|
#![doc = include_str!("../../../examples/storage_fetch.rs")]
|
|
//! ```
|
|
//!
|
|
//! For completeness, below is an example using a dynamic query instead. The return type from a
|
|
//! dynamic query is a [`crate::dynamic::DecodedValueThunk`], which can be decoded into a
|
|
//! [`crate::dynamic::Value`], or else the raw bytes can be accessed instead.
|
|
//!
|
|
//! ```rust,ignore
|
|
#![doc = include_str!("../../../examples/storage_fetch_dynamic.rs")]
|
|
//! ```
|
|
//!
|
|
//! ### Iterating storage entries
|
|
//!
|
|
//! Many storage entries are maps of values; as well as fetching individual values, it's possible to
|
|
//! iterate over all of the values stored at that location:
|
|
//!
|
|
//! ```rust,ignore
|
|
#![doc = include_str!("../../../examples/storage_iterating.rs")]
|
|
//! ```
|
|
//!
|
|
//! Here's the same logic but using dynamically constructed values instead:
|
|
//!
|
|
//! ```rust,ignore
|
|
#![doc = include_str!("../../../examples/storage_iterating_dynamic.rs")]
|
|
//! ```
|
|
//!
|
|
//! Here is an example of iterating over partial keys. In this example some multi-signature operations
|
|
//! are sent to the node. We can iterate over the pending multisig operations of a single multisig account:
|
|
//!
|
|
//! ```rust,ignore
|
|
#![doc = include_str!("../../../examples/storage_iterating_partial.rs")]
|
|
//! ```
|
|
//!
|
|
//! ### Advanced
|
|
//!
|
|
//! For more advanced use cases, have a look at [`crate::storage::Storage::fetch_raw`] and
|
|
//! [`crate::storage::Storage::fetch_raw_keys`]. Both of these take raw bytes as arguments, which can be
|
|
//! obtained from a [`crate::storage::StorageAddress`] by using
|
|
//! [`crate::storage::StorageClient::address_bytes()`] or
|
|
//! [`crate::storage::StorageClient::address_root_bytes()`].
|
|
//!
|