Is it planned to support storage iterations?

[bkchr]

Is it planned to support any kind of storage iterations? Similar to the current state_getKeysPaged in Substrate?

[bkchr]

CC @tomaka

[tomaka]

It's not planned but we can add it.

We can definitely add it to the archive_ API.

For the chainHead_ API, however, it's more complicated. I haven't implemented "getting the next key" anywhere in the light client yet, so I'm not sure how much networking it involves.

[bkchr]

Yeah, at least having it in archive_ would be nice. Would you see this/like to see that we have here all the things documented in this spec that are related to JSON rpc in Substrate? Probably yes or?
There is maybe some other stuff that needs to be documented here, otherwise people will be unhappy with the new api probably.

I haven't implemented "getting the next key" anywhere in the light client yet, so I'm not sure how much networking it involves.

That is a good question. I think the main question would here be, can we build UIs without this? Maybe a dumb question as this for sure would be possible, but maybe more complicated UIs need this kind of support.

[tomaka]

Would you see this/like to see that we have here all the things documented in this spec that are related to JSON rpc in Substrate? Probably yes or?

Sorry I don't get the question.

I think the main question would here be, can we build UIs without this?

Thinking about it, the JSON-RPC functions that allow you to access the storage are here to allow you to access the keys indicated by the metadata. For example, if the metadata tells you "information X is at key K", you then try to read key K.
As far as I know, the metadata tells you that there are maps, and so it makes sense to give the possibility to list all the elements of a map, in other words all the keys that start with a certain prefix.

So I don't think that "get the next key" makes sense, however "get all the keys that start with a certain prefix" makes sense to me.
I've already implemented this in the light client by asking for a Merkle proof of the prefix and then following the items in the proof.

[bkchr]

Sorry I don't get the question.

What I meant is that there are maybe some other RPC functions which are not yet specified here. So, that we may also have some other functions that need to be described here.

So I don't think that "get the next key" makes sense, however "get all the keys that start with a certain prefix" makes sense to me.
I've already implemented this in the light client by asking for a Merkle proof of the prefix and then following the items in the proof.

In the end probably boils down to the same. I think one of the reasons for having this kind of "iteration" support on the JSON rpc level is that there are maps that are too big to send at once, so you do multiple requests to fetch them. The best would be some kind of stream to poll for elements (you could still fetch all keys at once with a storage proof for example). However, this is probably not supported by JSON rpc?