On Jan 21, 2007, at 3:34 AM, Chris Hostetter wrote:
: "index" : {
: "numDocs" : 10123,
: "maxDoc" : 12345,
: "age" : 2000, #number of milliseconds the index has been
open... sort of equivalent to index freshness, but not really.
: "version":123425235, #index version. Actually, I think this
should be in responseHeader to aid in client-side caching
: }
:
: I think this stuff is useful, it's just a matter of preference if it
: goes in the same handler or not. If this *does* go in this
handler, then
: perhaps it should be named "indexinfo" or something. I'd be fine
with
: this hander being only about schema too though.
+1 to all of that ... "IndexInfo" seeems like a good thing for
returning
all sorts of info, of which the field list is just one piece
... I think
adding the stuff yonik listed above definitely makes sense in the same
request handler that reutrns the list of fields ...
Done!
This particular request handler will do wonders for the Flare side of
things, just you wait and see :)
the TermEnum iteration
with docFreq might make more sense in a seperate request handler if
for no
other reason then to simplify the API when paginating through terms
Agreed. I'm not sure why anyone would want docFreq that included
terms from documents that had been deleted though, so there should at
least be a warning in the documentation that says this particular
information is best done on an optimized index.
I'm curious what use case is envisioned for docFreqs that aren't
"faceted" in that they aren't constrained by some query to limit the
results. I certainly can see it being cool to navigate all the terms
of a field in a general sense of transparency, but narrowing down the
terms only from a particular sub-set of documents is what my
application needs.
Erik
