On 2/10/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: As for future expansion, some possibilities are: filter.op/filter.q.op : (set operator of filter query parser, which is currently OR regardless I'm not sure why/how thta would ever make sense... you'd be much better off using seperate filters so they can cache independently - not to mention the reason q.op was added was for dealing with user entered query strings, but are filter queries ever entered manually by a user?
See below.
: of the solrconfig setting), filter.range, and filter.q.noncached : (something I would definitely use if it existed). filter range could just be done with a filter.query/fq right? a
It sure could, but I was just trying to stretch my imagination as far as possible. filter.term also seems to me like only a marginal improvement over lucene syntax. -Mike
