-
Notifications
You must be signed in to change notification settings - Fork 337
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
RawRange
query
#2190
Comments
The big difference between the two cases is that I think in this case it is a bit hard decide which fields belong in the main query and which fields are pagination-related because it's somewhat all the same. The analogous query in wasmd is this: AllContractState (https://github.com/CosmWasm/wasmd/blob/v0.52.0/proto/cosmwasm/wasm/v1/query.proto#L154-L161). What this is missing is:
That being said, at some place in the query request we need to add:
Then the response needs to indicate
|
Alright, so we have our own enum QueryRequest {
// ...
RawRange {
contract_address: String,
/// Inclusive bound
start: Option<Vec<u8>>,
/// Exclusive bound
end: Option<Vec<u8>>,
/// Maximum number of elements to return
limit: u16,
/// The order in which you want to receive the key-value pairs
order: Order,
}
}
struct RawRangeResponse {
/// The key-value pairs
data: Vec<Record>,
/// `None` if there are no more key-value pairs
next_key: Option<Vec<u8>>,
} Some points:
|
We currently have a way to read from and range through our own storage, but for external storage we can only read a single key using
WasmQuery::Raw
.We should add a way to query a range of keys from an external contract.
This should be paginated to be able to avoid gas / memory exhaustion if the external contract is not fully trusted.
Something like this?
I'm a little conflicted here because on the one side it would be nice to stay close to the way
Storage::range
works (start, end, order), but with that it's not as easy to control the amount of items you get. Using theend
key for that is impractical because it leads to very short responses in sparsely populated maps. We could add an additionallimit
to that, but then it becomes a bit complicated to reason about.The text was updated successfully, but these errors were encountered: