This was prompted by some ideas put forth in SOLR-247 and in the mailing list threads linked to from that issue. See also: SOLR-456

For now this is a brainstorming page, if/when any of this gets implemented it can be reworked into a documentation page for users.


Currently the fl param supports two "special" field names: "*" which means "any stored field", and "score" which not only means "include the score in the response", but also informs the request handler that scores should be computed. the fl param is split on the regex Pattern ",| ".

The splitting happens in SolrPluginUtils.setReturnFields, which parses (one and only one) string "fl" param, and sets the field list on the SolrQueryResponse, as well as returning info about whether or not the list contained "score" so the handler has that info to work with.

Small problems with this (that most people have never cared about)...

Some people expressed a desire to have "*" work for the facet.field param as well ... see SOLR-247 for reasons why this is probably a bad idea, but having more generic glob syntax support (in both the "fl" and "facet.field" params) would be handy.

related issues

Broad Idea

Add robust support for letting solr admins configure what special syntax or aliases can be used *at query type* to refer to fields based on context (sorting, returned fields, search fields, facet fields, etc...)

new syntax in solrconfig.xml -- most of which should be on a per handler basis (probably via a new Component) -- that let's Solr administrators say things like:

...all of these things should be combinable in an order specified by the solr admin, they can say things like "when dealing with the facet.field param, let users specify regexes to identify the fields to facet on, and map the string "price" to the field "price_dollars_facet" but ultimately ignore any field that doesn't match the glob "*_facet"


The best way to do this may be to have a Component which can be configured with all of these rules (and reused by multiple handlers). The component would parse the input params, error if neccessary, and construct an object put into the request context that subsequent Components can call methods on to get field name Sets (or iterators) based on the param name being processed, the schema, the rules defined, the context of operation (ie: dealing with stored fields, dealing with indexed indexed fields, a specific document for returned fields, etc...)

It should not be too difficult if one uses the "new" queryParser mechanism from Lucene contrib. The Processor/Builder chain is suited for these changes. All this aliasing can be configured by configfile or on a per request basis.

FieldAliasesAndGlobsInParams (last edited 2011-01-24 22:56:05 by HossMan)