(Erik: Or he can get the LucidWorks Search product and then use "near" and
"before" operators so that he doesn't need the surround query parser!)
-- Jack Krupansky
-----Original Message-----
From: Erik Hatcher
Sent: Thursday, May 16, 2013 6:11 PM
To: solr-user@lucene.apache.org
Subject: Re: SurroundQParser does not analyze the query text
The issue can certainly be "solved". But to me, it's actually a bit of a
"feature" by design for the Lucene-level surround query parser to not do
analysis, as it seems to have been meant for advanced query writers to piece
together sophisticated SpanQuery-based pattern matching kinds of things
utilizing their knowledge of how text was analyzed and indexed.
But for sure it could be modified to do analysis, probably using the
"multiterm" analyzer feature in there now elsewhere now. I looked into this
when I did the basic work of integrating the surround query parser, and
determined it was a lot of work because it'd need changes in the Lucene
level code to leverage analysis, and then glue at the Solr level to be field
type aware and savvy.
By all means open and JIRA and contribute!
Workaround? Client-side calls can be made to analyze text, and the
client-side could build up a query expression based on term-by-term (or
phrase) analysis results. Maybe that means a prohibitive number of requests
to Solr to build up a query in a way that leverages Solr's field type
analysis settings, but it is a technologically possible technique maybe
worth considering.
Erik
On May 16, 2013, at 16:38 , Isaac Hebsh wrote:
Hi,
I'm trying to use Surround Query Parser for two reasons, which are not
covered by proximity slops:
1. find documents with two words within a given distance, *unordered*
2. given two lists of words, find documents with (at least) one word from
list A and (at least) one word from list B, within a given distance.
The surround query parser looks great, but it have one big drawback - It
does not analyze the query text. It is documented in the [weak :(] wiki
page.
Can this issue be solved somehow, or it is a bigger constraint?
Should I open a JIRA issue for this?
Any work-around?
