lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: listing/enumerating field information
Date Sun, 21 Jan 2007 03:58:22 GMT

On Jan 19, 2007, at 11:34 PM, Yonik Seeley wrote:

> On 1/19/07, Erik Hatcher <erik@ehatchersolutions.com> 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



Mime
View raw message