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

[XDCR] Adv filtering some number functions not working as expected

    XMLWordPrintable

Details

    • Untriaged
    • Centos 64-bit
    • No

    Description

      According to the design doc, niql number functions are supported in adv filtering, but ASIN and ACOS functions are not working as expected.
      https://docs.google.com/document/d/19PkXWG8ovTS-E7l2Fqg_kRwsPTh_wHhjrrFBFPOWzQs/edit?pli=1#heading=h.jue93z4nyvp5

      However, ATAN() in adv filter matches niql results.

      doc:

      {
        "string_short": "x",
        "string_medium": ")nx.\n\tPfDEEptfV2o",
        "int": 93,
        "float": 16.770881608010846,
        "string_long": "KfdVIYXB4Hk@uA9ZrChdOGP\r^lEd/l lQaAEoqGTfznioxXTsxlDy\fkBWmIiAe\nRPqm6.-\\RK%ZE&WzSn)rvt_IJi",
        "string_vlong": "egof$\ryps<QmEaQhg",
        "bool": false
      }
      

      working filter (the doc matches this filter and is replicated to target):
      ATAN(int)<>3.05682983181e+307

      not working (doc matches filter but is NOT replicated to target):
      ASIN(int)<>3.05682983181e+307
      ACOS(int)<>3.05682983181e+307

      Following queries return 1 when the above doc is present in src:

      SELECT COUNT(*) FROM default WHERE 'ACOS(int)<>3.05682983181e+307'
      SELECT COUNT(*) FROM default WHERE 'ASIN(int)<>3.05682983181e+307' 
      

      Attachments

        Issue Links

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

          Activity

            pavithra.mahamani Pavithra Mahamani created issue -
            pavithra.mahamani Pavithra Mahamani made changes -
            Field Original Value New Value
            Description According to the design doc, niql number functions are supported in adv filtering, but ASIN and ACOS functions are not working as expected.
            https://docs.google.com/document/d/19PkXWG8ovTS-E7l2Fqg_kRwsPTh_wHhjrrFBFPOWzQs/edit?pli=1#heading=h.jue93z4nyvp5

            However, ATAN() in adv filter matches niql results.

            doc:
            {
              "string_short": "x",
              "string_medium": ")nx.\n\tPfDEEptfV2o",
              "int": 93,
              "float": 16.770881608010846,
              "string_long": "KfdVIYXB4Hk@uA9ZrChdOGP\r^lEd/l lQaAEoqGTfznioxXTsxlDy\fkBWmIiAe\nRPqm6.-\\RK%ZE&WzSn)rvt_IJi",
              "string_vlong": "egof$\ryps<QmEaQhg",
              "bool": false
            }

            working filter (the doc matches this filter and is replicated to target):
            ATAN(int)<>3.05682983181e+307

            not working (doc matches filter but is NOT replicated to target):
            ASIN(int)<>3.05682983181e+307
            ACOS(int)<>3.05682983181e+307

            Following queries return 1 when the above doc is present in src:
            {noformat}
            SELECT COUNT(*) FROM default WHERE 'ACOS(int)<>3.05682983181e+307'
            SELECT COUNT(*) FROM default WHERE 'ASIN(int)<>3.05682983181e+307'
            {noformat}
            According to the design doc, niql number functions are supported in adv filtering, but ASIN and ACOS functions are not working as expected.
            https://docs.google.com/document/d/19PkXWG8ovTS-E7l2Fqg_kRwsPTh_wHhjrrFBFPOWzQs/edit?pli=1#heading=h.jue93z4nyvp5

            However, ATAN() in adv filter matches niql results.

            doc:
            {noformat}
            {
              "string_short": "x",
              "string_medium": ")nx.\n\tPfDEEptfV2o",
              "int": 93,
              "float": 16.770881608010846,
              "string_long": "KfdVIYXB4Hk@uA9ZrChdOGP\r^lEd/l lQaAEoqGTfznioxXTsxlDy\fkBWmIiAe\nRPqm6.-\\RK%ZE&WzSn)rvt_IJi",
              "string_vlong": "egof$\ryps<QmEaQhg",
              "bool": false
            }
            {noformat}

            working filter (the doc matches this filter and is replicated to target):
            ATAN(int)<>3.05682983181e+307

            not working (doc matches filter but is NOT replicated to target):
            ASIN(int)<>3.05682983181e+307
            ACOS(int)<>3.05682983181e+307

            Following queries return 1 when the above doc is present in src:
            {noformat}
            SELECT COUNT(*) FROM default WHERE 'ACOS(int)<>3.05682983181e+307'
            SELECT COUNT(*) FROM default WHERE 'ASIN(int)<>3.05682983181e+307'
            {noformat}
            pavithra.mahamani Pavithra Mahamani made changes -
            pavithra.mahamani Pavithra Mahamani added a comment - Just observed that when int = 0 or 1, docs are getting replicated to target. So the problem occurs only when int>1. https://s3.amazonaws.com/cb-engineering/Pavithra/collectinfo-2019-09-20T165550-ns_1%40172.23.105.133.zip https://s3.amazonaws.com/cb-engineering/Pavithra/collectinfo-2019-09-20T165550-ns_1%40172.23.106.121.zip
            neil.huang Neil Huang made changes -
            neil.huang Neil Huang made changes -
            neil.huang Neil Huang added a comment -

            Asin(93) is an imaginary number...

            Atan(93) seems to be a real number

            neil.huang Neil Huang added a comment - Asin(93) is an imaginary number... Atan(93) seems to be a real number
            pavithra.mahamani Pavithra Mahamani made changes -
            Labels releasenote
            neil.huang Neil Huang added a comment -

            Golang output the imaginary number result as "NaN", which stands for "Not-A-Number".

            I think it is fair for gojsonsm matcher to check for NaN.

            neil.huang Neil Huang added a comment - Golang output the imaginary number result as "NaN", which stands for "Not-A-Number". I think it is fair for gojsonsm matcher to check for NaN.
            pavithra.mahamani Pavithra Mahamani made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            lynn.straus Lynn Straus made changes -
            Labels releasenote approved-for-mad-hatter releasenote
            lynn.straus Lynn Straus added a comment -

            per Oct 14 email from John L, this is on track to be fixed by Nov 11.  Adding label "approved-for-Mad-Hatter"

            lynn.straus Lynn Straus added a comment - per Oct 14 email from John L, this is on track to be fixed by Nov 11.  Adding label "approved-for-Mad-Hatter"
            lynn.straus Lynn Straus added a comment -

            Added due date field (preset to Nov 15). Please update the due date to the current ETA for a fix. Thanks.

            lynn.straus Lynn Straus added a comment - Added due date field (preset to Nov 15). Please update the due date to the current ETA for a fix. Thanks.
            lynn.straus Lynn Straus made changes -
            Due Date 15/Nov/19
            neil.huang Neil Huang added a comment -

            https://github.com/couchbaselabs/gojsonsm/pull/119 is now in gojsonsm repository. Build automation should kick in soon with a new build

            neil.huang Neil Huang added a comment - https://github.com/couchbaselabs/gojsonsm/pull/119 is now in gojsonsm repository. Build automation should kick in soon with a new build
            neil.huang Neil Huang made changes -
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Resolved [ 5 ]
            neil.huang Neil Huang made changes -
            Is this a Regression? Unknown [ 10452 ] No [ 10451 ]
            neil.huang Neil Huang made changes -
            Labels approved-for-mad-hatter releasenote approved-for-mad-hatter documentation releasenote

            Build couchbase-server-6.5.0-4754 contains gojsonsm commit abdb374 with commit message:
            MB-36088 - Refactored much of data type comparisons and added N1QL-like collate to fast matcher

            build-team Couchbase Build Team added a comment - Build couchbase-server-6.5.0-4754 contains gojsonsm commit abdb374 with commit message: MB-36088 - Refactored much of data type comparisons and added N1QL-like collate to fast matcher

            Build couchbase-server-6.5.0-4754 contains gojsonsm commit 0e8f997 with commit message:
            MB-36088 - implement NaN float comparisons

            build-team Couchbase Build Team added a comment - Build couchbase-server-6.5.0-4754 contains gojsonsm commit 0e8f997 with commit message: MB-36088 - implement NaN float comparisons

            Build couchbase-server-7.0.0-1034 contains gojsonsm commit abdb374 with commit message:
            MB-36088 - Refactored much of data type comparisons and added N1QL-like collate to fast matcher

            build-team Couchbase Build Team added a comment - Build couchbase-server-7.0.0-1034 contains gojsonsm commit abdb374 with commit message: MB-36088 - Refactored much of data type comparisons and added N1QL-like collate to fast matcher

            Build couchbase-server-7.0.0-1034 contains gojsonsm commit 0e8f997 with commit message:
            MB-36088 - implement NaN float comparisons

            build-team Couchbase Build Team added a comment - Build couchbase-server-7.0.0-1034 contains gojsonsm commit 0e8f997 with commit message: MB-36088 - implement NaN float comparisons
            neil.huang Neil Huang made changes -
            Link This issue blocks MB-36851 [ MB-36851 ]
            neil.huang Neil Huang made changes -
            Link This issue blocks DOC-5993 [ DOC-5993 ]

            Verified this behavior on 6.5.0-4821:

            Any NaN (not-a-number) float values will be considered less than any other real number, and two NaNs will not yield equality. The only exception is the operators “<=” and “>=” would break this paradigm and return “true”. This is different from golang’s standards where NaNs are not equal when compared regardless of function. Applications using gojsonsm such as XDCR can check for collation.

            pavithra.mahamani Pavithra Mahamani added a comment - Verified this behavior on 6.5.0-4821: Any NaN (not-a-number) float values will be considered less than any other real number, and two NaNs will not yield equality. The only exception is the operators “<=” and “>=” would break this paradigm and return “true”. This is different from golang’s standards where NaNs are not equal when compared regardless of function. Applications using gojsonsm such as XDCR can check for collation.
            pavithra.mahamani Pavithra Mahamani made changes -
            VERIFICATION STEPS Verified this behavior on 6.5.0-4821:

            Any NaN (not-a-number) float values will be considered less than any other real number, and two NaNs will not yield equality. The only exception is the operators “<=” and “>=” would break this paradigm and return “true”. This is different from golang’s standards where NaNs are not equal when compared regardless of function. Applications using gojsonsm such as XDCR can check for collation.
            Status Resolved [ 5 ] Closed [ 6 ]

            People

              neil.huang Neil Huang
              pavithra.mahamani Pavithra Mahamani
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty