Sevag H

https://github.com/sevagh/pq/pull/76

Wanna test this hotfix? [pq-bin.tar.gz](https://github.com/sevagh/pq/files/1488928/pq-bin.tar.gz) It uses rust nightly to recursively peak inside the JSON and modify all keys. `1.0.2`

Nightly should have no serious implications, a lot of real production Rust code uses nightly. >PS: if I understand correctly, what your are currently doing is a post-processing of the...

``` sevagh:pq $ ./tests/python/proto_encoder.py single nested | ./target/debug/pq --fdsetfile ./tests/fdsets/parent_child_nested.fdset --msgtype Parent --canonical { "myChild": { "fooBar": "baz" } } sevagh:pq $ ./tests/python/proto_encoder.py single map | ./target/debug/pq --fdsetfile ./tests/fdsets/parent_child_map.fdset --msgtype...

Some more thoughts on the upstream/canonical JSON handling question: * rust-protobuf provides the lowest level of protobuf code. It doesn't care about JSON * serde-protobuf deserializes protobuf into `serde_value` objects....

I'll whip up a test case. I didn't notice the "RepeatedField" which defeats my `Seq` scan expectation.

It fails on this footgun. At this point distinguishing a RepeatedField from a real map is impossible. That one needs to be upstream.

Interestingly, look at what I find when I peak into the `FileDescriptorSet` object: ``` fdset: file { name: "schemata/parent_child_nested.proto" message_type { name: "Parent" field { name: "my_child" number: 1 label:...

This code will take some time to think about and implement correctly. I'll be MIA for the next month so it will take time!

Thanks for contributing BTW. Hope we can find a solution to this eventually.