[jira] [Created] (SOLR-3261) edismax ignores explicit operators when literal colon is found

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Created] (SOLR-3261) edismax ignores explicit operators when literal colon is found

Hudson (Jira)
edismax ignores explicit operators when literal colon is found
--------------------------------------------------------------

                 Key: SOLR-3261
                 URL: https://issues.apache.org/jira/browse/SOLR-3261
             Project: Solr
          Issue Type: Bug
            Reporter: Hoss Man


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...
{noformat}
+(DisjunctionMaxQuery((a_t:bogus:xxx | b_t:bogus:xxx)) DisjunctionMaxQuery((a_t:and | b_t:and)) text_t:yak)
{noformat}

(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...
{noformat}
+(+foo_s:xxx +text_t:yak)
{noformat}

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


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (SOLR-3261) edismax ignores explicit operators when literal colon is found

Hudson (Jira)

     [ https://issues.apache.org/jira/browse/SOLR-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juan Grande updated SOLR-3261:
------------------------------

    Attachment: SOLR-3261.patch

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

               

> edismax ignores explicit operators when literal colon is found
> --------------------------------------------------------------
>
>                 Key: SOLR-3261
>                 URL: https://issues.apache.org/jira/browse/SOLR-3261
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: SOLR-3261.patch
>
>
> 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...
> {noformat}
> +(DisjunctionMaxQuery((a_t:bogus:xxx | b_t:bogus:xxx)) DisjunctionMaxQuery((a_t:and | b_t:and)) text_t:yak)
> {noformat}
> (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...
> {noformat}
> +(+foo_s:xxx +text_t:yak)
> {noformat}
> (this problem also seems to affect trunk circa 2012-03-20)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] [Issue Comment Edited] (SOLR-3261) edismax ignores explicit operators when literal colon is found

Hudson (Jira)
In reply to this post by Hudson (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237743#comment-13237743 ]

Juan Grande edited comment on SOLR-3261 at 3/25/12 12:28 AM:
-------------------------------------------------------------

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

               
      was (Author: juangrande):
    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

                 

> edismax ignores explicit operators when literal colon is found
> --------------------------------------------------------------
>
>                 Key: SOLR-3261
>                 URL: https://issues.apache.org/jira/browse/SOLR-3261
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: SOLR-3261.patch
>
>
> 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...
> {noformat}
> +(DisjunctionMaxQuery((a_t:bogus:xxx | b_t:bogus:xxx)) DisjunctionMaxQuery((a_t:and | b_t:and)) text_t:yak)
> {noformat}
> (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...
> {noformat}
> +(+foo_s:xxx +text_t:yak)
> {noformat}
> (this problem also seems to affect trunk circa 2012-03-20)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (SOLR-3261) edismax ignores explicit operators when literal colon is found

Hudson (Jira)
In reply to this post by Hudson (Jira)

     [ https://issues.apache.org/jira/browse/SOLR-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated SOLR-3261:
---------------------------

    Attachment: SOLR-3261.patch

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
               

> edismax ignores explicit operators when literal colon is found
> --------------------------------------------------------------
>
>                 Key: SOLR-3261
>                 URL: https://issues.apache.org/jira/browse/SOLR-3261
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: SOLR-3261.patch, SOLR-3261.patch
>
>
> 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...
> {noformat}
> +(DisjunctionMaxQuery((a_t:bogus:xxx | b_t:bogus:xxx)) DisjunctionMaxQuery((a_t:and | b_t:and)) text_t:yak)
> {noformat}
> (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...
> {noformat}
> +(+foo_s:xxx +text_t:yak)
> {noformat}
> (this problem also seems to affect trunk circa 2012-03-20)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (SOLR-3261) edismax ignores explicit operators when literal colon is found

Hudson (Jira)
In reply to this post by Hudson (Jira)

     [ https://issues.apache.org/jira/browse/SOLR-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated SOLR-3261:
---------------------------

      Component/s: query parsers
    Fix Version/s: 4.0
                   3.6
   

> edismax ignores explicit operators when literal colon is found
> --------------------------------------------------------------
>
>                 Key: SOLR-3261
>                 URL: https://issues.apache.org/jira/browse/SOLR-3261
>             Project: Solr
>          Issue Type: Bug
>          Components: query parsers
>            Reporter: Hoss Man
>             Fix For: 3.6, 4.0
>
>         Attachments: SOLR-3261.patch, SOLR-3261.patch
>
>
> 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...
> {noformat}
> +(DisjunctionMaxQuery((a_t:bogus:xxx | b_t:bogus:xxx)) DisjunctionMaxQuery((a_t:and | b_t:and)) text_t:yak)
> {noformat}
> (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...
> {noformat}
> +(+foo_s:xxx +text_t:yak)
> {noformat}
> (this problem also seems to affect trunk circa 2012-03-20)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] [Assigned] (SOLR-3261) edismax ignores explicit operators when literal colon is found

Hudson (Jira)
In reply to this post by Hudson (Jira)

     [ https://issues.apache.org/jira/browse/SOLR-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man reassigned SOLR-3261:
------------------------------

    Assignee: Hoss Man
   

> edismax ignores explicit operators when literal colon is found
> --------------------------------------------------------------
>
>                 Key: SOLR-3261
>                 URL: https://issues.apache.org/jira/browse/SOLR-3261
>             Project: Solr
>          Issue Type: Bug
>          Components: query parsers
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>             Fix For: 3.6, 4.0
>
>         Attachments: SOLR-3261.patch, SOLR-3261.patch
>
>
> 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...
> {noformat}
> +(DisjunctionMaxQuery((a_t:bogus:xxx | b_t:bogus:xxx)) DisjunctionMaxQuery((a_t:and | b_t:and)) text_t:yak)
> {noformat}
> (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...
> {noformat}
> +(+foo_s:xxx +text_t:yak)
> {noformat}
> (this problem also seems to affect trunk circa 2012-03-20)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] [Resolved] (SOLR-3261) edismax ignores explicit operators when literal colon is found

Hudson (Jira)
In reply to this post by Hudson (Jira)

     [ https://issues.apache.org/jira/browse/SOLR-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man resolved SOLR-3261.
----------------------------

    Resolution: Fixed
      Assignee: Juan Grande  (was: Hoss Man)

Committed revision 1306054.
Committed revision 1306059.

thanks for figuring this out Juan!
               

> edismax ignores explicit operators when literal colon is found
> --------------------------------------------------------------
>
>                 Key: SOLR-3261
>                 URL: https://issues.apache.org/jira/browse/SOLR-3261
>             Project: Solr
>          Issue Type: Bug
>          Components: query parsers
>            Reporter: Hoss Man
>            Assignee: Juan Grande
>             Fix For: 3.6, 4.0
>
>         Attachments: SOLR-3261.patch, SOLR-3261.patch
>
>
> 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...
> {noformat}
> +(DisjunctionMaxQuery((a_t:bogus:xxx | b_t:bogus:xxx)) DisjunctionMaxQuery((a_t:and | b_t:and)) text_t:yak)
> {noformat}
> (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...
> {noformat}
> +(+foo_s:xxx +text_t:yak)
> {noformat}
> (this problem also seems to affect trunk circa 2012-03-20)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]