Closed webmaster128 closed 4 years ago
Yeah, I was expecting normal utf-8 strings for keys, and this would allow a more natural approach - the client could submit un-encoded queries, such as "config", rather than base64 encoding it.
I do agree that &[u8]
is more general, and what is needed when you are handling binary bytes as db keys. For calling between contracts, it actually makes complete sense, as even if you want to use a string, the only difference is using RawQuery{ key:
b"config"}instead of
RawQuery{ key: "config"}
, as the json codec would take care of the base64 encoding.
I guess we can do the same json encoding in any client code as well, and just use standard base64 binary encoding for all values in the internal interfaces.
I approve this change and will make a PR to address it. This will unblock https://github.com/confio/cosmwasm-examples/pull/10
This may be removed when we refactor queries as discussed in #72 and #73
Closing as obsolete from 0.6 on. I think this is a wontfix for 0.5.x.
Right now,
RawQuery
expresses the database key as a string.This limited the use of RawQuery to keys which are valid UTF-8.
Both the ERC20 token contract as well as the following function signature expect support for arbitrary binary keys:
pub fn raw_query(key: &[u8]) -> Result<Vec<u8>> {
.Using a hex or base64 encoded binary string would allow arbitrary key queries.