This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Macro for constructing a high-level type-safe wrapper around substrate storage #78
Comments
4 tasks
what is this fascination with collecting common lexicographical items into crates!? while i agree with the general gist of this issue, storage elements should be declared (and exported as needed) in the modules that use them, not in some monolithic collection, just like constants, types, helper functions and tests. |
@gavofyork sure, then those particular keys like |
In general the goal of extracting the constants out to a separate crate is to allow type-safe access of the storage without having to link to the entire runtime. |
Merged
JoshOrndorff
added a commit
to moonbeam-foundation/substrate
that referenced
this issue
Apr 21, 2021
* Adds H160 account * Check in Cargo.lock * Fix no_std build * Fixes token-dealer account id * Setup chain_specs for H160 AccountId * Adds license * Cleans H160 account.rs * Clean warnings * Fixes account reference * format rust files * More rust format fixes * Fixes genesis spec for H160 * Adds test for polkadotjs balance check * Fixes test specs * Restore AccountId logic * Replace AccountId20 by H160 + fix tests * Clean formatting * Fix extra whitespace * Fixes warning messages * Fixes errors in merge * Adds dev/ops account to alphanet specs Co-authored-by: Alan <alan@ip-172-31-37-206.us-east-2.compute.internal> Co-authored-by: Joshy Orndorff <admin@joshyorndorff.com> Co-authored-by: Alan Sapede <alan@scg-moonbuild-1.dev.purestake.tech>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Goal: never reference or load storage items using the key string directly. It is arcane, bug-prone, and unreadable.
usage:
Using a
trait Storage
:crate
substrate_storage
would define all storage values used in substrate.crate
polkadot_storage
would define all storage values used in polkadot.The "load"/"store" API is a little annoying, so under runtime-support we would provide a Storage implementation that calls out to the externalities and a trait to provide helpers that are more ergonomic: i.e. a
load()
andstore(T)
function which are usable only within the runtime.Usage in runtime:
The text was updated successfully, but these errors were encountered: