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

META().expiration gives wrong results for non-covered index

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.0
    • Fix Version/s: 5.5.0, Spock.Next
    • Component/s: query
    • Labels:
      None
    • Triage:
      Untriaged
    • Is this a Regression?:
      Unknown

      Description

      META().expiration uses covered index it gives right results. When used non covered index it gives 0.

      This needs to be documented for Spock may not be addressable in Spock due to following reasons.

      1) N1QL fetches data from memecached using GET. The GET call is not includes expiration, seqno, etc...
      2) To get this information we need to do GET_META call.
      3) Making additional call for each key for SELECT/UPDATE... etc can cause latency can be doubled and through put drops drastically. Also the data between two calls can be out of sync.

      The possible solution is defined new protocol and pass as bit flags that what information needed as single call.

      Repro :
      -----------

      brew install libcouchbase
      cbc create foo -V "{\"test\":\"bar\"}"  -U couchbase://127.0.0.1/default   -e 1000000 -u Administrator -P password
      

      create index ixdi on default(meta().expiration);
      select meta().id, meta().expiration from default where meta().expiration is not null;
      --- covered index. above select gives one row.
      select meta().id, meta().expiration, xxx from default where meta().expiration is not null;
      --- non covered index, no rows given
      
      

      See MB-15950 and it comments more details.

        Attachments

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

          Activity

          Hide
          pvarley Patrick Varley added a comment -

          3) Making additional call for each key for SELECT/UPDATE... etc can cause latency can be doubled and through put drops drastically. Also the data between two calls can be out of sync.

          Subdoc with XATTR does this in 5.0

          Show
          pvarley Patrick Varley added a comment - 3) Making additional call for each key for SELECT/UPDATE... etc can cause latency can be doubled and through put drops drastically. Also the data between two calls can be out of sync. Subdoc with XATTR does this in 5.0
          Hide
          drigby Dave Rigby added a comment -

          Subdoc with XATTR does this in 5.0

          Specifically, see the $Document.exptime Virtual Attribute: https://docs.google.com/document/d/18UVa5j8KyufnLLy29VObbWRtoBn9vs8pcxttuMt6rz8/edit?ts=598d8972#heading=h.d320vz4h95e7. Added to memcached via: http://review.couchbase.org/77099

          Show
          drigby Dave Rigby added a comment - Subdoc with XATTR does this in 5.0 Specifically, see the $Document.exptime Virtual Attribute: https://docs.google.com/document/d/18UVa5j8KyufnLLy29VObbWRtoBn9vs8pcxttuMt6rz8/edit?ts=598d8972#heading=h.d320vz4h95e7 . Added to memcached via: http://review.couchbase.org/77099
          Hide
          isha Isha Kandaswamy added a comment -

          I tried retrieving exptime - using subdoc with xattr but i got 0

          Get result

          doc contents – map[test:bar]

          $document val – map[deleted:false last_modified:1515782901 CAS:0x15092484a13d0000 vbucket_uuid:0x000078697bcd4da7 seqno:0x0000000000000002 exptime:0 value_bytes:14 datatype:[json xattr]]

          _sync val – map[name:string id:int value]

          The actual document shows the following 

           

          {
          "id": "foo",
          "rev": "1-150924637c4d00005a6844a700000000",
          "expiration": 1516782759,
          "flags": 0
          }

           

          Show
          isha Isha Kandaswamy added a comment - I tried retrieving exptime - using subdoc with xattr but i got 0 Get result doc contents – map [test:bar] $document val – map[deleted:false last_modified:1515782901 CAS:0x15092484a13d0000 vbucket_uuid:0x000078697bcd4da7 seqno:0x0000000000000002 exptime:0 value_bytes:14 datatype: [json xattr] ] _sync val – map [name:string id:int value] The actual document shows the following    { "id": "foo", "rev": "1-150924637c4d00005a6844a700000000", "expiration": 1516782759, "flags": 0 }  
          Hide
          keshav Keshav Murthy added a comment -

          For non-covered queries, you DO need to use a xattr reference so we get the expiration.  This is the expected behavior.

           

          select default.*,meta().expiration from default let v = meta().xattrs.`$document`;
          {
           "requestID": "729fd64f-010e-4388-8438-f3a49c000bf3",
           "signature": {
           "*": "*",
           "expiration": "json"
           },
           "results": [
           {
           "expiration": 1519542818,
           "test": "bar"
           }
           ],
           "status": "success",
           "metrics": {
           "elapsedTime": "9.328508ms",
           "executionTime": "9.31134ms",
           "resultCount": 1,
           "resultSize": 75
           }
          }

          Show
          keshav Keshav Murthy added a comment - For non-covered queries, you DO need to use a xattr reference so we get the expiration.  This is the expected behavior.   select default .*,meta().expiration from default let v = meta().xattrs.`$document`; { "requestID" : "729fd64f-010e-4388-8438-f3a49c000bf3" , "signature" : { "*" : "*" , "expiration" : "json" }, "results" : [ { "expiration" : 1519542818 , "test" : "bar" } ], "status" : "success" , "metrics" : { "elapsedTime" : "9.328508ms" , "executionTime" : "9.31134ms" , "resultCount" : 1 , "resultSize" : 75 } }
          Hide
          arunkumar Arunkumar Senthilnathan added a comment -

          closing no fix issues for vulcan

          Show
          arunkumar Arunkumar Senthilnathan added a comment - closing no fix issues for vulcan

            People

            • Assignee:
              isha Isha Kandaswamy
              Reporter:
              Sitaram.Vemulapalli Sitaram Vemulapalli
            • Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Gerrit Reviews

                There are no open Gerrit changes

                  PagerDuty

                  Error rendering 'com.pagerduty.jira-server-plugin:PagerDuty'. Please contact your Jira administrators.