: 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)
-Hoss
