Hi Patrick,
have you added that SynonymFilter to the index chain and the query
chain? You have to add it to both if you want to have it replaced at
index and query time. It might also be enough to add it to the query
chain only. Than your index still preserves the original data.
Cheers,
Chantal
Patrick Jungermann schrieb:
Hi Koji,
using phrase queries is no alternative for us, because all query parts
has to be optional parts. The phrase query workaround will work for a
query "foo bar", but only for this exact query. If the user queries for
"foo bar baz", it will be changed to "foo_bar baz", but it will not
match the indexed documents that only contains "foo_bar". And this is,
what we need here.
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.
Patrick
Koji Sekiguchi schrieb:
Patrick,
parsedQueryString was something similar to "field:foo field:bar". At
index time, it works like expected.
I guess because you are searching q=foo bar, this causes OR query.
Use q="foo bar", instead.
Koji
Patrick Jungermann wrote:
Hi list,
I worked on a field type and its analyzing chain, at which I want to use
the SynonymFilter with entries similar to:
foo bar=>foo_bar
During the analysis phase, I used the /admin/analysis.jsp view to test
the analyzing results produced by the created field type. The output
shows that a query "foo bar" will first be separated by the
WhitespaceTokenizer to the two tokens "foo" and "bar", and that the
SynonymFilter will replace the both tokens with "foo_bar". But as I
tried this at "real" query time with the request handler "standard" and
also with "dismax", the tokens "foo" and "bar" were not replaced. The
parsedQueryString was something similar to "field:foo field:bar". At
index time, it works like expected.
Has anybody experienced this and/or knows a workaround, a solution for
it?
Thanks, Patrick
