Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Sun, 25 Mar 2012 00:28:25 +0000 (UTC)
From: "Juan Grande (Updated) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1700504367.13844.1332635305686.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1897301679.38690.1332279578230.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (SOLR-3261) edismax ignores explicit operators
 when literal colon is found
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org