Test that the JSON coding works #16
Conversation
Add a test that decodes a JSON object, and detect links in it. Then encode
it again and it must match the original file. The test failed (because the
link was a map[string]interface{} instead of a Node). The fix post-process
the result of the JSON decoder to convert map[string]interface{} to Node.
|
ah, thanks @mildred -- yes we should test cbor too. sad that we have to run another pass through the whole thing. the ugorji codec used to let you define the type-- do we know if the json codec can do that? |
|
We cannot directly. What we can do is parse the JSON as a token stream, and construct whatever data structure we want, but it is a bit more involved and does not adheres the multicodec interface The json package also let us declare our type to be a There is an issue that talks about something similar to the |
|
:/ sucks. definitely throws off our IPLD groove. I think the cbor marshaller does allow this-- maybe im totally off. if not, we should look into adding it. parsing json is slow anyway, and this convert step wont be a big deal, but in the cbor case, we want that to be as fast as possible. (json too, but ok to slack a bit for while) |
|
@whyrusleeping keep an eye on all these issues as IPLD is close to landing. dont want to be caught unaware |
I tried to test that decoding JSON actually worked and we could get links from it, and it failed. The problem was that the link object was a
map[string]interface{}and not aNode. This was the issue described in issue #3, perhaps we should reopen it as there is likely a similar issue with cbor.