CosmWasm / wasmd

Basic cosmos-sdk app with web assembly smart contracts
Other
364 stars 396 forks source link

`wasmd query wasm contract-state all --DECODE` flag #1550

Open dzmitry-lahoda opened 1 year ago

dzmitry-lahoda commented 1 year ago

Can we have query to dump all state and decode it?

No I need to write some bash/jq/xxd/base64 script loop or smart queries:

wasmd query wasm contract-state all $CONTRACT $NODE --output "json" | jq -r '.models[0].key' | xxd -r -ps
wasmd query wasm contract-state all $CONTRACT $NODE --output "json" | jq -r '.models[0].value' | base64 -d

So in my cases I just want dump state of contract and read it in my dev/debug loop, but decoded

Is this worth to add? My be such tools exists and I miss it.

alpe commented 1 year ago

Technically, it would not be hard to decode keys and values in the CLI but they can be anything. Not likely human readable or nice to render on the shell. What would be your preferred output format?

dzmitry-lahoda commented 1 year ago

i saw that in our case, keys are glue of some readable and non redable parts, but part is readable is enough to identify what the key is. some attemp to decode to unicode ignoring non decodable parts is good enough. like some editors do when I open binary files, definitely i see some usefull text inside (e.g. open wasm binary and see strings here mixed with some binary bytes). so some unicode would be usefull.

Values are json in our case. I assume values most people write are json too. And that why base64 encoding. So unicode string output is okey.

dzmitry-lahoda commented 1 year ago

problem for me is, okey to map one key and value via xxd/base64, but when I just want to dump whatever in contract and see it snapshow state, i will have to build looping with jq. it seem to complicate for fast view of data in bash, defeats the purpose. and i write queries which just dump whole state. actually ideal solution for storage to have schema too kind of, which is query impl for all data.

but hack in cli is good enough, and will work with contracts without schema. if their key/values are pb encoding for example, one layer of encoding onion is removed. so cli decoding is sloppy, but good enough in most cases.

webmaster128 commented 1 year ago

Sounds plausible to me, especially if the goal is to improve the "dev/debug loop" where you can always dig deeper if you need more precise information but often don't.

I suggest an implementation equivalent to from_utf8_lossy but did not find a Go version for that easily.