You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 iteratelet storage_query = polkadot::storage().system().account_iter();// Get back an iterator of resultsletmut results = api.storage().at_latest().await?.iter(storage_query).await?;whileletSome(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.pubfnas_key(&self) -> Result<Option<KeyType>,Error>{ ...}// Just return all of the key bytes.pubfnbytes(&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!
The text was updated successfully, but these errors were encountered:
Storage keys are often formed from
_concat
style hashers, which are formed fromconcat(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:
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: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!
The text was updated successfully, but these errors were encountered: