lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Luke request handler issue
Date Wed, 23 May 2007 02:00:34 GMT
Ryan - just so you know where my current need with this is, it's only  
in getting field names and types, as well as total documents back.   
The top terms aren't a need for my projects.  So I don't really have  
any preference on the specifics, other than needing to be able to  
turn that feature off :)


On May 22, 2007, at 9:56 PM, Ryan McKinley wrote:

> Ryan McKinley wrote:
>> Yonik Seeley wrote:
>>> The whole topTerms thing is exactly the same concept as faceting
>>> with *:* as a base (with perhaps the exception of ignoring deleted
>>> docs by using df?)
>>> Should these parameters be aligned somehow?
>> Using the faceting implementation would be good too... since you  
>> would get the all the caching etc.
>> maybe it can directly use faceting parameters (and implementation)  
>> for "topTerms" -- if nothing is specified for "facet.field", it  
>> will add all fields (alternatively, normal faceting could support  
>> *, but that seems like a bad idea in the general case)
>> I'll take a look at that and see how it feels...
> There are a few show stoppers with that idea.... most notable the  
> faceting implementation needs a solr field.  Much of the motivation  
> for the LukeRequestHandler is to inspect an index regardless of  
> what solr thinks about it.
> - - - -
> How do you imagine the parameters would be aligned?
> It could use the same per/field specification:
>  f.category.facet.limit=5
> perhaps it Luke should support:
>   and
> I'm reluctant to go this route because it makes asking if any we  
> should calculate top terms or not difficut (ok, akward) and i'm not  
> sure it helps that much...
> I'll make a JIRA issue with a simple implementation you all can  
> poke at.
> ryan

View raw message