Solr
  1. Solr
  2. SOLR-3261

edismax ignores explicit operators when literal colon is found

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6, 4.0-ALPHA
    • Component/s: query parsers
    • Labels:
      None

      Description

      Using the 3.5 example this query...

      q = bogus:xxx AND text_t:yak
      http://localhost:8983/solr/select/?debugQuery=true&qf=a_t+b_t&defType=edismax&mm=0&q=bogus:xxx+AND+text_t:yak

      parses as...

      +(DisjunctionMaxQuery((a_t:bogus:xxx | b_t:bogus:xxx)) DisjunctionMaxQuery((a_t:and | b_t:and)) text_t:yak)
      

      (Note that "AND" is considered a term and is searched for in the qf fields)

      But this query...
      q = foo_s:xxx AND text_t:yak
      http://localhost:8983/solr/select/?debugQuery=true&qf=a_t+b_t&defType=edismax&mm=0&q=foo_s:xxx+AND+text_t:yak

      parses correctly treating AND as an explicit operator...

      +(+foo_s:xxx +text_t:yak)
      

      (this problem also seems to affect trunk circa 2012-03-20)

      1. SOLR-3261.patch
        5 kB
        Hoss Man
      2. SOLR-3261.patch
        4 kB
        Juan Grande

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          Committed revision 1306054.
          Committed revision 1306059.

          thanks for figuring this out Juan!

          Show
          Hoss Man added a comment - Committed revision 1306054. Committed revision 1306059. thanks for figuring this out Juan!
          Hide
          Hoss Man added a comment -

          updated version of Juan's patch with some test improvements:

          • tweaked the name to make it more clear we were testing the behavior with literal colons (not that there was anything invalid about the requests)
          • tweaked the assertions to be explicit about which docs should match, not just how many
          • added a doc with literal AND and NOT values to make sure we weren't matching stray docs.

          ...still running full tests, but i'm aiming to commit this to trunk and 3.6 ASAP

          Show
          Hoss Man added a comment - updated version of Juan's patch with some test improvements: tweaked the name to make it more clear we were testing the behavior with literal colons (not that there was anything invalid about the requests) tweaked the assertions to be explicit about which docs should match, not just how many added a doc with literal AND and NOT values to make sure we weren't matching stray docs. ...still running full tests, but i'm aiming to commit this to trunk and 3.6 ASAP
          Hide
          Juan Grande added a comment - - edited

          Hi,

          I'm attaching a patch that solves this issue.

          The problem was that when an inexistent field occurred in the query, the raw (unescaped) Clause was used, so ExtendedSolrQueryParser failed and then the query was re-parsed with operators quoted.

          For existent but non-allowed fields the behavior was different: all the special characters in the clause were escaped in the first place.

          With my patch, when an inexistent or non-allowed field is found, only the colons are escaped, the rest of the clause is left unmodified. There is the special case of *:*, where the colon is not escaped.

          The patch was made for trunk, but it applies (with some warnings from "patch") to branch_3x. All tests pass for me!

          Juan

          Show
          Juan Grande added a comment - - edited Hi, I'm attaching a patch that solves this issue. The problem was that when an inexistent field occurred in the query, the raw (unescaped) Clause was used, so ExtendedSolrQueryParser failed and then the query was re-parsed with operators quoted. For existent but non-allowed fields the behavior was different: all the special characters in the clause were escaped in the first place. With my patch, when an inexistent or non-allowed field is found, only the colons are escaped, the rest of the clause is left unmodified. There is the special case of *:*, where the colon is not escaped. The patch was made for trunk, but it applies (with some warnings from "patch") to branch_3x. All tests pass for me! Juan

            People

            • Assignee:
              Juan Grande
              Reporter:
              Hoss Man
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development