On 2/9/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
On Feb 9, 2007, at 9:16 PM, Mike Klaas wrote:
> Might I suggest:
>
> filter.query
> filter.term
> filter.
I like it. While Hoss has a point, though descriptive names do make
a lot of sense too. It has been a bit confusing to explain
facet.que
: > > filter.query
: > > filter.term
: > > filter.
: 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/f
I applied the patch here (split_sort.txt)
https://issues.apache.org/jira/browse/SOLR-140
I then recompiled this version: apache-solr-1.1.0-incubating
using: ant compile then ant dist
I then copied:
/opt/apache-solr-1.1.0-incubating/dist/apache-solr-1.1.1-dev-incubating.war
as solr.war, and d
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 fil
The feature list included in the Solr website says solr provides
"Support for Dynamic Result Grouping". I can't find any documentation
on the website explaining what this is, or how one would go about
using it.
Anyone care to enlighten me?
On 2/11/07, Brendan Ribera <[EMAIL PROTECTED]> wrote:
The feature list included in the Solr website says solr provides
"Support for Dynamic Result Grouping".
It's faceting (grouping by field value dynamically).
I later learned that people commonly use "grouping" in a different
sense, so it's pr
: 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.
the only reason i suggested filter.term at all was because it eliminates
hte need to worry baout quoting/escaping when dealin
