Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-7069

Fix UI to support Non-JSON values ( was: Non-JSON values which are not integers show up as base-64 encoded when viewed through the UI document viewer)

    Details

    • Type: Improvement
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: feature-backlog
    • Component/s: ns_server
    • Security Level: Public
    • Labels:
      None

      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...

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        perry Perry Krug created issue -
        farshid Farshid Ghods (Inactive) made changes -
        Field Original Value New Value
        Fix Version/s 2.0 [ 10114 ]
        Hide
        chiyoung Chiyoung Seo added a comment -

        Farshid,

        Please assign this bug to the view or UI team. ep-engine has nothing to do with view and its UI.

        Show
        chiyoung Chiyoung Seo added a comment - Farshid, Please assign this bug to the view or UI team. ep-engine has nothing to do with view and its UI.
        chiyoung Chiyoung Seo made changes -
        Assignee Chiyoung Seo [ chiyoung ] Farshid Ghods [ farshid ]
        Hide
        farshid Farshid Ghods (Inactive) added a comment -

        Perry,

        can you please specify whether the document was an ascii or a binary data ?

        Show
        farshid Farshid Ghods (Inactive) added a comment - Perry, can you please specify whether the document was an ascii or a binary data ?
        Hide
        perry Perry Krug added a comment -

        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.

        Show
        perry Perry Krug added a comment - 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.
        Hide
        deepkaran.salooja Deepkaran Salooja added a comment -

        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).

        Show
        deepkaran.salooja Deepkaran Salooja added a comment - 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 Deepkaran Salooja made changes -
        Attachment StringAsNonJson.png [ 15672 ]
        Attachment StringNumbersAsValidJson.png [ 15673 ]
        Hide
        farshid Farshid Ghods (Inactive) added a comment -

        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 ?

        Show
        farshid Farshid Ghods (Inactive) added a comment - 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 ?
        farshid Farshid Ghods (Inactive) made changes -
        Summary Non-JSON values show up as garbled binary when viewed through the UI document viewer Non-JSON values which are not integers show up as garbled binary when viewed through the UI document viewer
        farshid Farshid Ghods (Inactive) made changes -
        Summary Non-JSON values which are not integers show up as garbled binary when viewed through the UI document viewer Non-JSON values which are not integers show up as base-64 encoded when viewed through the UI document viewer
        farshid Farshid Ghods (Inactive) made changes -
        Labels customer 2.0-release-notes customer
        Assignee Farshid Ghods [ farshid ] MC Brown [ mccouch ]
        Hide
        farshid Farshid Ghods (Inactive) added a comment -

        for 2.0 i marked this to be documented since our documented editing section is not meant for non-json values ( e.g http://www.couchbase.com/issues/browse/MB-7031)

        Show
        farshid Farshid Ghods (Inactive) added a comment - for 2.0 i marked this to be documented since our documented editing section is not meant for non-json values ( e.g http://www.couchbase.com/issues/browse/MB-7031 )
        Hide
        perry Perry Krug added a comment -

        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

        Show
        perry Perry Krug added a comment - 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
        Hide
        farshid Farshid Ghods (Inactive) added a comment -

        >>.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.

        Show
        farshid Farshid Ghods (Inactive) added a comment - >>.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.
        Hide
        perry Perry Krug added a comment -

        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.

        Show
        perry Perry Krug added a comment - 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.
        dipti Dipti Borkar made changes -
        Component/s documentation [ 10012 ]
        Hide
        mccouch MC Brown (Inactive) added a comment -

        Note has been added to the corresponding section of the docs,and to the release notes.

        Show
        mccouch MC Brown (Inactive) added a comment - Note has been added to the corresponding section of the docs,and to the release notes.
        mccouch MC Brown (Inactive) made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        perry Perry Krug added a comment -

        Reopening as it's still not clear whether this is something we want to support or not...and I argue that we should.

        Show
        perry Perry Krug added a comment - Reopening as it's still not clear whether this is something we want to support or not...and I argue that we should.
        perry Perry Krug made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Assignee MC Brown [ mccouch ] Dipti Borkar [ dipti ]
        Hide
        dipti Dipti Borkar added a comment -

        The UI does not handle BLOB data very well. Data access using the APIs for BLOBs is completely supported and works well.

        Show
        dipti Dipti Borkar added a comment - The UI does not handle BLOB data very well. Data access using the APIs for BLOBs is completely supported and works well.
        dipti Dipti Borkar made changes -
        Summary Non-JSON values which are not integers show up as base-64 encoded when viewed through the UI document viewer Fix UI to support Non-JSON values ( was: Non-JSON values which are not integers show up as base-64 encoded when viewed through the UI document viewer)
        Issue Type Bug [ 1 ] Improvement [ 4 ]
        Assignee Dipti Borkar [ dipti ] Aleksey Kondratenko [ alkondratenko ]
        Fix Version/s .next [ 10342 ]
        Fix Version/s 2.0 [ 10114 ]
        mikew Mike Wiederhold made changes -
        Component/s ns_server [ 10019 ]
        Component/s couchbase-bucket [ 10173 ]
        kzeller kzeller made changes -
        Component/s documentation [ 10012 ]
        Hide
        kzeller kzeller added a comment -

        Removing docs tag, additional server work required. Reassign when ready to document post-resolution.

        Show
        kzeller kzeller added a comment - Removing docs tag, additional server work required. Reassign when ready to document post-resolution.
        alkondratenko Aleksey Kondratenko (Inactive) made changes -
        Labels 2.0-release-notes customer ns_server-story
        Hide
        alkondratenko Aleksey Kondratenko (Inactive) added a comment -

        As discussed I'm not seeing any sensible way to support arbitrary values and don't think it's worth trying to.

        Show
        alkondratenko Aleksey Kondratenko (Inactive) added a comment - As discussed I'm not seeing any sensible way to support arbitrary values and don't think it's worth trying to.
        alkondratenko Aleksey Kondratenko (Inactive) made changes -
        Labels ns_server-story
        Assignee Aleksey Kondratenko [ alkondratenko ] Anil Kumar [ anil ]
        Hide
        perry Perry Krug added a comment -

        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?

        Show
        perry Perry Krug added a comment - 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?
        Hide
        alkondratenko Aleksey Kondratenko (Inactive) added a comment -

        If you want specifically to support strings and integers then please ask specifically for that. And work with Anil on spec.

        Show
        alkondratenko Aleksey Kondratenko (Inactive) added a comment - If you want specifically to support strings and integers then please ask specifically for that. And work with Anil on spec.

          People

          • Assignee:
            anil Anil Kumar
            Reporter:
            perry Perry Krug
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Gerrit Reviews

              There are no open Gerrit changes