Yonik Seeley wrote:
On 5/22/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
I think all the features of the Luke request handler should be made
optional, except for just feeding back the fields and types in the
index which seems a reasonable always-on feature.
+1
The feature list of this handler could grow, and I think having
explicit ways to turn them on is the right way to go (like
standard/dismax request handlers have for faceting, highlighting, etc)
-Yonik
Sounds good... There are two reasons you would turn on/off options:
speed and display.
Since many of the features are calculated together, we need a parameter
interface that makes sense. For example, turning off "TopTerms" also
turns off "distinct terms" and the histogram... If you want the
histogram, but not the the TopTerms, it takes the same time - and even
calculates the TopTerms - but does not return them
A quick look of features/hierarchy you may want to turn on/off:
* indexinfo (numDocs, maxDocs, etc)
* terms (has to walk through reader.terms())
* distinct (simple ++)
* top (PriorityQueue)
* histogram (Hash)
* luceneFieldInfo (has too call "fieldName:[* TO *]")
* flags
* numDocs
* key
One option would be to enumerate these features and have a boolean param
for each thing in the hierarchy. If the parent is set, but none of the
children, it assumes true for all of them.
For example: (assuming the default for everything is false)
/luke?return.indexinfo=on&return.terms=true
would return:
indexinifo,
terms.distinct,
terms.top,
terms.histogram
/luke?return.terms.histogram=true
would return only return:
terms.histogram
(but not top terms would still be computed)
Perhaps there should also be a:
return.default=true/false
that decides what the default for *all* of the features is.
Thoughts? Is this what you had in mind? Is there a better parameter
name to consider then "return.terms=false"?
ryan
