Details

Description

Reproduction:
-Set a key with some non-JSON value
-View that key through the document viewer in the UI
-See that the value does not match what was just set

I presume this is because we are compressing the data at the disk level and then reading that binary attachment back when viewing through the UI...but it's quite confusing for the user to not be able to see what they thought was simple string data.

Does this at all affect views of non-JSON (i.e., increment counters)? Even in the random doc preview, this data does not come across correctly...

Ascii. I tried both a few characters in string and a single integer value (as if it were an increment counter value).

This came up from a customer who created a CSV list and wanted to view it through the UI as well as design a view around it.

I'm fairly certain the problem is that this mechanism for viewing documents is coming directly from the on-disk datastore (as opposed to through memcached) and therefore it is compressed binary and not exactly what the application put in.

Perry Krug
added a comment - 01/Nov/12 4:32 AM Ascii. I tried both a few characters in string and a single integer value (as if it were an increment counter value).
This came up from a customer who created a CSV list and wanted to view it through the UI as well as design a view around it.
I'm fairly certain the problem is that this mechanism for viewing documents is coming directly from the on-disk datastore (as opposed to through memcached) and therefore it is compressed binary and not exactly what the application put in.
Let me know if you need more specific reproduction details.

Anything which doesn't parse as valid json are encoded as base64 and stored as an attachment. In the UI for document viewer these get displayed as binary.
There was a recent bug fix for the increment counter values. So string integers will show up fine as they now parse as valid JSONs(screenshot attached-StringNumbersAsValidJson). Please see MB-6961 for detailed discussion.
For normal strings, these will get displayed as binary(screenshot-StringAsNonJson).

Deepkaran Salooja
added a comment - 01/Nov/12 11:06 AM Anything which doesn't parse as valid json are encoded as base64 and stored as an attachment. In the UI for document viewer these get displayed as binary.
There was a recent bug fix for the increment counter values. So string integers will show up fine as they now parse as valid JSONs(screenshot attached-StringNumbersAsValidJson). Please see MB-6961 for detailed discussion.
For normal strings, these will get displayed as binary(screenshot-StringAsNonJson).

Farshid Ghods (Inactive)
added a comment - 01/Nov/12 11:15 AM resolving this as won't fix since this is an expected behavior as mentioned in the last comment
the fix for this would be to reverse the base64 coding ?

Perry Krug
added a comment - 01/Nov/12 11:23 AM Sorry if it should be obvious...but this is already fixed in a later release and so just have to document for the beta? Or is it planned for this never to be supported?
Thanks Farshid

Farshid Ghods (Inactive)
added a comment - 01/Nov/12 11:29 AM >>.but this is already fixed in a later release
viewing non-json values on document editing page is not supported or expected behavior.
however as Deep mentioned a corner case is fixed in MB-6961
once 7031 is merged ( before 2.0 GA ) user will see a better error message when document is non-json
so for 2.0 GA we need to document that this behavior is not supported and expected.

Okay, I might need to question that a little bit...how is a user supposed to write a view around a non-JSON (i.e. an incremement counter or CSV) if they can't see it in the document viewer? Writing such views is supposed to be supported right? Seems like this would have to be as well?

Obviously document it for whenever we can't, but I think Dipti needs to decide how to address it.

Perry Krug
added a comment - 01/Nov/12 11:43 AM Okay, I might need to question that a little bit...how is a user supposed to write a view around a non-JSON (i.e. an incremement counter or CSV) if they can't see it in the document viewer? Writing such views is supposed to be supported right? Seems like this would have to be as well?
Obviously document it for whenever we can't, but I think Dipti needs to decide how to address it.

This does come up on a fairly regular basis, especially since we do advocate using strings and integers within our documents (as non-JSON) and yet we don't display them properly in the UI. Could we just do a base64 decode on the value and display whatever returns from that?

Perry Krug
added a comment - 12/Aug/13 10:54 AM This does come up on a fairly regular basis, especially since we do advocate using strings and integers within our documents (as non-JSON) and yet we don't display them properly in the UI. Could we just do a base64 decode on the value and display whatever returns from that?