Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we be more helpful re decoding storage keys? #1201

Closed
jsdw opened this issue Oct 9, 2023 · 0 comments · Fixed by #1419
Closed

Can we be more helpful re decoding storage keys? #1201

jsdw opened this issue Oct 9, 2023 · 0 comments · Fixed by #1419
Assignees

Comments

@jsdw
Copy link
Collaborator

jsdw commented Oct 9, 2023

Storage keys are often formed from _concat style hashers, which are formed from concat(hash(scale_encoded_key), scale_encoded_key).

In theory, we know what the types of the different keys and hashers are when iterating over storage values, and so we might be able to provide back properly typed keys (when _concat hashers are used at least) as well as properly typed values.

I think that the ideal interface to aim for would be that we could do:

// Build a storage query to iterate
let storage_query = polkadot::storage().system().account_iter();

// Get back an iterator of results
let mut results = api.storage().at_latest().await?.iter(storage_query).await?;

while let Some(Ok((key, value))) = results.next().await {
    // Here, key is ideally of a type like `StorageKey<AccountId>` and value is `AccountInfo`.
    // currently, key is `Vec<u8>`
}

Ok(())

When there are multiple keys, could we return a tuple of eg (StorageKey<Foo>, StorageKey<Bar>)?

StorageKey would be a struct that has a method on it like:

impl <KeyType: DecodeAsType> StorageKey {
    // Try to decode key into the type given,
    // where the type might be Value or something for dynamic queries,
    // and None if the hasher wasn't a `_concat` one.
    pub fn as_key(&self) -> Result<Option<KeyType>, Error> { ... }

    // Just return all of the key bytes.
    pub fn bytes(&self) -> &[u8] { ... }
}

When the storage query is dynamic, we could use StorageKey<Value> maybe to dynamically decode the key instead where possible.

There may be quirks and caveats to this idea that haven't crossed my mind yet!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants