lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juan Grande (Updated) (JIRA)" <>
Subject [jira] [Updated] (SOLR-3261) edismax ignores explicit operators when literal colon is found
Date Sun, 25 Mar 2012 00:28:25 GMT


Juan Grande updated SOLR-3261:

    Attachment: SOLR-3261.patch


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

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!


> edismax ignores explicit operators when literal colon is found
> --------------------------------------------------------------
>                 Key: SOLR-3261
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message