wasmd query wasm contract-state all --DECODE flag

[dzmitry-lahoda]

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]

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]

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]

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]

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.