Thanks Hoss, after your hints that had partially confirmed my considerations, I had made some tests with the FieldQParser. At the beginning, I had have some problems, but finally, I was able to solve the problem of multi-word synonyms at query time in a way that is suitable for us - and possibly for others, too.
At my solution, I re-used the FieldQParserPlugin. At first, I ported it to the new API (incrementToken instead of next, etc.) and then I modified the code so, that no PhraseQueries will be created but only BooleanQueries. Now with my new QParserPlugin that based on the FieldQParserPlugin, it's possible to search for things like "foo bar baz", where "foo bar" has to be changed to "foo_bar" and where at the end the tokens "foo_bar" und "baz" will be created, so that both could match independently. Patrick Chris Hostetter schrieb: > : The cause of my problem should be the query parsing, but I don't know, > : if there is any solution for it. I need a possibility that works like > : the analysis/query parsing within /admin/analysis.jsp view. > > The behavior you are describing is very well documented on the wiki... > http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory > > in general, QueryParsers parse input strigs according to their > parsing rules, then send each component of th input string to the > analyzer. this is a fundentmal behavior, w/o it the query parser would > have no way of knowing when to make a phrase query, or a term query, or > which field to use. > > You may find something like the FieldQParserPlugin helpful as it has *no* > markup of it's own, it just hands the string off to an analyzer based on > the specified field ... but it will still generate a phrase query when a > single piece of input generates multiple tokens with non-zero offsets from > eachother, which also confuses people sometimes (not sure if that's what > you'd want) > > : >> SynonymFilter will replace the both tokens with "foo_bar". But as I > : >> tried this at "real" query time with the request handler "standard" and > > you've used the phrase '"real" query time' (in contrast to analysis.jsp) a > few times in this thread ... to be clear about something: there is nothing > different between analysis.jsp and what happens when a query is executed, > the reason you see different behavior is because you are pasteeing what > you consider a "query string" into the analysis form, but that's not what > happens at query time, and it's not what that form expects -- that form is > designed for users to paste in the strings that the query parser would > extract from it's query syntax. it's not suprising that you'll get > something different then if you just did a straight search on the same > input, any different then it would be suprising if pasting > "fieldname:value +otherfield:value" in analysis.jsp didn't produce the > same tokens as a query for that string. > > > -Hoss > > From - Fri
