mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-16 16:41:10 +00:00
make spellcheck green again (#6059)
* make spellcheck green again * remove the comment * Fix a comment in `provisioner` Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io>
This commit is contained in:
@@ -21,18 +21,18 @@
|
||||
//! (which is versioned) or they can be staging (aka unstable/testing
|
||||
//! functions).
|
||||
//!
|
||||
//! The separation outlined above is achieved with the versioned api feature
|
||||
//! The separation outlined above is achieved with the versioned API feature
|
||||
//! of `decl_runtime_apis!` and `impl_runtime_apis!`. Before moving on let's
|
||||
//! see a quick example about how api versioning works.
|
||||
//! see a quick example about how API versioning works.
|
||||
//!
|
||||
//! # Runtime api versioning crash course
|
||||
//! # Runtime API versioning crash course
|
||||
//!
|
||||
//! The versioning is achieved with the `api_version` attribute. It can be
|
||||
//! placed on:
|
||||
//! * trait declaration - represents the base version of the api.
|
||||
//! * trait declaration - represents the base version of the API.
|
||||
//! * method declaration (inside a trait declaration) - represents a versioned
|
||||
//! method, which is not available in the base version.
|
||||
//! * trait implementation - represents which version of the api is being
|
||||
//! * trait implementation - represents which version of the API is being
|
||||
//! implemented.
|
||||
//!
|
||||
//! Let's see a quick example:
|
||||
@@ -61,53 +61,53 @@
|
||||
//! }
|
||||
//! }
|
||||
//! ```
|
||||
//! A new api named `MyApi` is declared with `decl_runtime_apis!`. The trait declaration
|
||||
//! A new API named `MyApi` is declared with `decl_runtime_apis!`. The trait declaration
|
||||
//! has got an `api_version` attribute which represents its base version - 2 in this case.
|
||||
//!
|
||||
//! The api has got three methods - `fn1`, `fn2`, `fn3` and `fn4`. `fn3` and `fn4` has got
|
||||
//! The API has got three methods - `fn1`, `fn2`, `fn3` and `fn4`. `fn3` and `fn4` has got
|
||||
//! an `api_version` attribute which makes them versioned methods. These methods do not exist
|
||||
//! in the base version of the api. Behind the scenes the declaration above creates three
|
||||
//! runtime apis:
|
||||
//! * MyApiV2 with `fn1` and `fn2`
|
||||
//! * MyApiV3 with `fn1`, `fn2` and `fn3`.
|
||||
//! * MyApiV4 with `fn1`, `fn2`, `fn3` and `fn4`.
|
||||
//! in the base version of the API. Behind the scenes the declaration above creates three
|
||||
//! runtime APIs:
|
||||
//! * `MyApiV2` with `fn1` and `fn2`
|
||||
//! * `MyApiV3` with `fn1`, `fn2` and `fn3`.
|
||||
//! * `MyApiV4` with `fn1`, `fn2`, `fn3` and `fn4`.
|
||||
//!
|
||||
//! Please note that v4 contains all methods from v3, v3 all methods from v2 and so on.
|
||||
//! Please note that `v4` contains all methods from `v3`, `v3` all methods from `v2` and so on.
|
||||
//!
|
||||
//! Back to our example. At the end runtime api is implemented for `struct Runtime` with
|
||||
//! `impl_runtime_apis` macro. `api_version` attribute is attached to the impl block which
|
||||
//! Back to our example. At the end runtime API is implemented for `struct Runtime` with
|
||||
//! `impl_runtime_apis` macro. `api_version` attribute is attached to the `impl` block which
|
||||
//! means that a version different from the base one is being implemented - in our case this
|
||||
//! is v3.
|
||||
//! is `v3`.
|
||||
//!
|
||||
//! This version of the api contains three methods so the `impl` block has got definitions
|
||||
//! for them. Note that `fn4` is not implemented as it is not part of this version of the api.
|
||||
//! This version of the API contains three methods so the `impl` block has got definitions
|
||||
//! for them. Note that `fn4` is not implemented as it is not part of this version of the API.
|
||||
//! `impl_runtime_apis` generates a default implementation for it calling `unimplemented!()`.
|
||||
//!
|
||||
//! Hopefully this should be all you need to know in order to use versioned methods in the node.
|
||||
//! For more details about how the api versioning works refer to `spi_api`
|
||||
//! For more details about how the API versioning works refer to `spi_api`
|
||||
//! documentation [here](https://docs.substrate.io/rustdocs/latest/sp_api/macro.decl_runtime_apis.html).
|
||||
//!
|
||||
//! # How versioned methods are used for `ParachainHost`
|
||||
//!
|
||||
//! Let's introduce two types of `ParachainHost` api implementation:
|
||||
//! Let's introduce two types of `ParachainHost` API implementation:
|
||||
//! * stable - used on stable production networks like Polkadot and Kusama. There is only one
|
||||
//! stable api at a single point in time.
|
||||
//! stable API at a single point in time.
|
||||
//! * staging - used on test networks like Westend or Rococo. Depending on the development needs
|
||||
//! there can be zero, one or multiple staging apis.
|
||||
//! there can be zero, one or multiple staging APIs.
|
||||
//!
|
||||
//! The stable version of `ParachainHost` is indicated by the base version of the api. Any staging
|
||||
//! The stable version of `ParachainHost` is indicated by the base version of the API. Any staging
|
||||
//! method must use `api_version` attribute so that it is assigned to a specific version of a
|
||||
//! staging api. This way in a single declaration one can see what's the stable version of
|
||||
//! staging API. This way in a single declaration one can see what's the stable version of
|
||||
//! `ParachainHost` and what staging versions/functions are available.
|
||||
//!
|
||||
//! All stable api functions should use primitives from the latest version.
|
||||
//! In the time of writing of this document - this is v2. So for example:
|
||||
//! All stable API functions should use primitives from the latest version.
|
||||
//! In the time of writing of this document - this is `v2`. So for example:
|
||||
//! ```ignore
|
||||
//! fn validators() -> Vec<v2::ValidatorId>;
|
||||
//! ```
|
||||
//! indicates a function from the stable v2 API.
|
||||
//! indicates a function from the stable `v2` API.
|
||||
//!
|
||||
//! All staging api functions should use primitives from vstaging. They should be clearly separated
|
||||
//! All staging API functions should use primitives from `vstaging`. They should be clearly separated
|
||||
//! from the stable primitives.
|
||||
|
||||
use crate::v2;
|
||||
|
||||
Reference in New Issue
Block a user