: > > filter.query : > > filter.term : > > filter.<future expansion>
: I like self-documenting parameter names, but if there is concern about : verbosity, how 'bout: : : fq : fq.term no it's cool ... filter.query and filter.term are definitely better. : 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? : 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 non-cached fq might make sense though. -Hoss
