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?
