[
https://issues.apache.org/jira/browse/SOLR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466293
]
Yonik Seeley commented on SOLR-116:
-----------------------------------
Facets are slightly different than docfreq's... one is expensive, and one is
very cheap since it's pre-calculated by lucene.
The disad to the lucene version is that the docfreq doesn't take deleted docs
into account.
If you want to page through or download *all* terms of a full-text field, the
faceting code would take forever in comparison.
other ideas for info:
"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.
> StructureRequestHandler - allowing client to discover all fields in the index
> -----------------------------------------------------------------------------
>
> Key: SOLR-116
> URL: https://issues.apache.org/jira/browse/SOLR-116
> Project: Solr
> Issue Type: New Feature
> Components: search
> Reporter: Erik Hatcher
> Assigned To: Erik Hatcher
> Priority: Minor
> Attachments: structure_handler.patch
>
>
> This request handler returns all fields and their type. In Ruby format
> (&wt=ruby) the results, for the example index, look like this currently:
> {'responseHeader'=>{'status'=>0,'QTime'=>1},'fields'=>{'cat'=>'text_ws','includes'=>'text','id'=>'string','text'=>'text','price'=>'sfloat','features'=>'text','manu_exact'=>'string','manu'=>'text','name'=>'text','sku'=>'textTight','inStock'=>'boolean','popularity'=>'sint','weight'=>'sfloat'}}
> A client wanting to introspect Solr could combine the actual fields and their
> types with parsing of schema.xml to glean a lot and dynamically configure
> based on what is inside an index. Should more information per field be
> returned, or is simply the type name sufficient? What else is desirable for
> this request handler?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
