mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-26 13:31:07 +00:00
cheme
b0e1212d48
* Using child storage, (srml-support only), test failing . * fix simple tests. * Enumerable by requiring owned struct (previous form only allow &'static). Broken tests are from genesis init. * implement for_child_keys_with_prefix * indent * clear_child_prefix fix. * clear_child_prefix fix 2. * fix for storage_impl, if/when allowing child and not child this could be reverted. * Fix lot of urlinked child genesis, still need to look upon actual genesis srml module code. Probably still a lot of broken code needing debugging. * switch well_known_key to their associated module child trie. Fix a genesis init (balance). Complete some testing. Comment some tests before using. * fixing test runtime child keys * latest commit fix broken genesis init * fix system balances child name. * Important fix: storage_root from test externalities need children (it is already the case for ext). * executive root with child calculation * Avoid empty trie on test ext. * Symetric removal of key for system. * commenting changes related tests. * Remove child module specifics. * fix issues. * fix some formatting * fix bench and bump runtime * Remove extend_storage_overlays, assimilate_storage do the same as is proper considering srml macro. * Fix warning for assimilate. * Removing kill as they do not impact any test cases. * Use tuple of storage map instead of two parameters. This changes the behavior of decl_storage genesis build closure (breaking api). * Do not use build storage before assimilate. * fix error * Update core/state-machine/src/backend.rs
= SRML The Substrate Runtime Module Library (SRML) is a collection of runtime modules. == What are runtime modules? A Substrate runtime can be composed of several smaller components for separation of concerns. These components are called runtime _modules_. Each runtime module packages together a set of functions (dispatchable extrinsic calls, public or private, mutable or immutable), storage items, and events. There are four primary components that support runtime modules: === system module https://github.com/paritytech/substrate/tree/master/srml/system[`system`] provides low-level APIs and utilities for other modules. https://github.com/paritytech/substrate/tree/master/srml/system[`system`] also defines all core types and extrinsic events for the Substrate runtime. *All modules depend on the system module.* === executive module https://github.com/paritytech/substrate/tree/master/srml/executive[`executive`] dispatches incoming extrinsic calls to the respective modules in the runtime. === support macros https://github.com/paritytech/substrate/tree/master/srml/support[`support` macros] are a collection of Rust macros to facilitate the implementation of common module components. https://github.com/paritytech/substrate/tree/master/srml/support[`support` macros] expand at runtime to generate types (e.g. `Module`, `Call`, `Store`, `Event`) which are thereafter used by the runtime to communicate with the modules. Common support macros include https://crates.parity.io/srml_support/macro.decl_module.html[`decl_module`], https://crates.parity.io/srml_support_procedural/macro.decl_storage.html[`decl_storage`], https://crates.parity.io/srml_support/macro.decl_event.html[`decl_event`], and https://crates.parity.io/srml_support/macro.ensure.html[`ensure`]. === runtime The runtime expands the support macros to get type and trait implementations for each module before calling https://github.com/paritytech/substrate/tree/master/srml/executive[`executive`] to dispatch calls to the individual modules. To see an example of how this might look, see https://github.com/paritytech/substrate/blob/master/node/runtime/src/lib.rs[`../node/runtime`].