Thanks for the advice. I've moved this query rewriting logic (not really business logic) to a SearchComponent and will leave the custom query parser to deal with the keyword (q=) related aspects of the query. In my case, the latter is mostly dealing with the presence of wildcard characters.
Peter On Wed, Oct 22, 2014 at 6:35 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : It's for an optimization. If the keyword is 'match all docs', I want to > : remove a custom PostFilter from the query and change the sort parameters > : (so the app doesn't have to do it). It looks like the responseHeader is > : displaying the 'originalParams', which are immutable. > > that is in fact the point of including the params in the header - to make > it clear what exatly the request handler got as input. > > "echoParams" can be used to control wether you get "all" the params > (including those added as defaults/appens in configuration) or just the > "explicit" params included in the request -- but there's no way for a > QParserPlugin to change what the raw query param strings are -- the query > it produces might not even have a meaningful toString. > > the params in the header are there for the very explicit reason of showing > you exactly what input was used to produce this request -- if plugins > could change them, they would be meaningless since the modified params > might not produce the same request. > > if you want to have a custom plugin that applies business logic to hcnage > the behavior internally and reports back info for hte client to use in > future requests, i would suggest doing that as a SearchComponent and > inclding your own section in the response with details about what the > client should do moving forward. > > > (for example: i had a serach component once upon a time that applied > QueryElevationComponent type checking against the query string & filters, > and based on what it found would set the sort & add some filters unless an > explicit sort / filter params were provided by the client -- the sort & > filters that were added were included along with some additional metadat > about what "rule" was matched in a new section of the response.) > > > -Hoss > http://www.lucidworks.com/ >
