Thanks. If I knew where to begin to implement this, I would. It seems
to me that the constraining of field lists must occur at the very core
of Solr because of the reduction in search time when specifying a
restrictive set of fields to return. For example, when I return 10
entire documents the search takes a QTime of 170, which I presume is
milliseconds. However, the time it takes a browser to render the data
puts the actual time into seconds. When I restrict the field list with
"fl=id,name", the QTime is reduced to 24 -- not a small difference.
So, this leads me to believe that the application of field list
restrictions is not simply occurring in the response writer. Does
anyone know where it *is* occurring?
--
-a
"Ideally, a code library must be immediately usable by naive
developers, easily customized by more sophisticated developers, and
readily extensible by experts." -- L. Stein
On Mar 13, 2009, at 7:21 AM, Erik Hatcher wrote:
On Mar 12, 2009, at 1:43 PM, Schley Andrew Kutz wrote:
If I wanted to hack Solr so that it has the ability to process
wildcards for the field list parameter (fl), where would I look?
(Perhaps I should look on the solr-dev mailing list, but since I am
already on this one I thought I would start here). Thanks!
One strategy that can be used (and Solr Flare, a RoR plugin, employs
this) is to make a request to Solr's Luke request handler at client
startup (or whenever you want to "reset") to get a list of the
fields actually in the index and use that to build the field list
and other dynamically controlled things, like facet.field parameters.
For example, Flare takes all fields returned from the luke request
handler, and all that match *_facet become facet.field parameters in
the search requests.
Wasn't exactly an answer to your question. Wildcard support for
field names in Solr is a feature that really deserves broader
implementation consideration than just hacking one spot for fl.
Other field list parameters, like hl.fl could use that capability too.
Erik
