lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: listing/enumerating field information
Date Sat, 13 Jan 2007 01:26:35 GMT

: Sounds like this stuff could/should be extensions to the current facet.field

Yeah ... what Erik's talking about really sounds like a simple faceting
issue: supporting prefix's for limiting the list of constraints ... what
Tracey was talking about seems much more like Luke-esqe index info: what
are all the fields, and what are all the terms in those fields. (and what
is the docFreq of each of those terms)

: facet.field=year&f.year.facet.prefix=186
:   or
: facet.field=year,f.year.facet.terms=186*
:   or
: facet.terms=year:186*
: #the latter two forms could relatively easily allow for anything that
: could be converted
: #to a TermEnum, so all wildcards could be handled.  Just parse with
: the queryparser and
: # check what type of query comes out?

the notion of a bunch of "if (q instanceof PrefixQuery) { ... } else if
(q instanceof WildcardQuery) { ... } ..." doesn't really appeal to me ...
but i could certainly get on board a new "f.*.facet.prefix" param.

: >  Paging via start/
: > rows is necessary,
: Hmmm, really?  Not too hard I guess, but I'd be interested in how you use it.

yeah paginating facet constraints doesn't really make sense to me ...
unless you're just taling about paginated the main results like we already
do now.  for the facets themselves facet.limit seems good enough ..
especially since it already sorts.

I get why pagination is important in Tracey's use case though (where
she's just dumping all terms)


View raw message