On Jan 19, 2007, at 11:34 PM, Yonik Seeley wrote:
On 1/19/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
So, where are we with these things now?
The one delta for my use case is getting ones that start with a
certain prefix. I'll look into adding this when I can.
The code for most of these things is easy... the hardest part is
coming up with interfaces flexible enough that you don't box yourself
in later and make things ugly.
For example, how does one specify a prefix constraint while
faceting a field:
facet.field=myfield&f.myfield.terms=foo*
But what if you also wanted to facet a different way on the same field
in the same request?
When we came up with per-field params for highlighting, it worked well
because everything was field based. It no longer really is.
One could use (abuse) the per-field-param capability to do
something like:
facet.id=1
f.1.field=myfield
f.1.terms=foo*
facet.id=2
f.2.field=myfield
f.2.terns=bar*
I'm not impressed. I'm leaning toward being practical (punting and
going with the first form for now... the upshot being that you can't
facet on the same field multiple ways.)
Thoughts?
The latter example is overengineering this a bit. My use case is
simply to return terms that match a prefix within some given some
constraints (q + fq), and for each of those terms also return the
counts. Requesting more than one field for faceting isn't currently
needed. We're talking about a text box wired to some JavaScript that
returns the terms and counts back only for a single field.
I envisioned a specialized request handler that leverages what it can
from the existing faceting infrastructure. Though with your first
example, the standard handler would be sufficient. While it makes
perfect sense to return search results at the same time you request
facets (except for successive pages, when facets won't change, of
course), for the suggest behavior I'd set rows=0.
I personally tend towards smaller single purpose handlers rather than
trying to make the "standard" one do it all.
Erik
