If thats the case, I think the .diff you posted is fine...
The only thing I would change is I think the default should be some
positive number. For the app where you want the default to be 0, you
can initialize the request handler with:
<requestHandler ... >
<lst name="defaults">
<int name="numTerms">0</int>
</lst>
</requestHandler>
Erik Hatcher wrote:
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 :)
Erik
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:
terms.top=10
and
f.category.terms.top=10
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
