Thought about that again, We can do this work as a search component, manipulating the query string. The cons are the double QParser work, and the double tokenization work.
Another approach which might solve this issue easily is "Dynamic query analyze chain": https://issues.apache.org/jira/browse/SOLR-5053 What would you do? On Tue, Sep 17, 2013 at 10:31 PM, Isaac Hebsh <isaac.he...@gmail.com> wrote: > Hi everyone, > > We developed a TokenFilter. > It should act differently, depends on a parameter supplied in the > query (for query chain only, not the index one, of course). > We found no way to pass that parameter into the TokenFilter flow. I guess > that the root cause is because TokenFilter is a pure lucene object. > > As a last resort, we tried to pass the parameter as the first term in the > query text (q=...), and save it as a member of the TokenFilter instance. > > Although it is ugly, it might work fine. > But, the problem is that it is not guaranteed that all the terms of a > particular query will be analyzed by the same instance of a TokenFilter. In > this case, some terms will be analyzed without the required information of > that "parameter". We can produce such a race very easily. > > How should I overcome this issue? > Do anyone have a better resolution? >
