Chris, the confusion from my perspective is the general inconsistency and natural growth of the API which is somewhat expected based upon its history.
Obviously this isnt sql, there is no ansi body defining the query language. I understand well the difference between stored, indexed etc. Going off of the apache wiki docs (which perhaps is not the correct place to go for documentation buts its what google gives me :-}) http://wiki.apache.org/solr/CommonQueryParameters The fl parameter doesnt actually mention stored. It actually gives reference to a few "special" values, such as "id" and "score". Neither of them are technically "stored" fields either, but afaik you dont need to use "field(id), field(score)" for those. Can you honestly say that is consistent? So On Jul 17, 2013, at 5:30 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : Yes that worked, thanks Alan. The consistency of this api is "challenging". > > It's important to understand what's happening here. > > fl, by default, only returns "stored" fields -- but you can also request > "psuedo-fields" such as the results of functions, or the result of a "Doc > Transformer" ... > > http://wiki.apache.org/solr/CommonQueryParameters#fl > > On the other side of things, the ExtenalFileField has some very special > behavior that allows it to be used as the input to a function, but it does > not act as a true stored or indexed field -- it's completley external > to the index... > > https://lucene.apache.org/solr/4_3_1/solr-core/org/apache/solr/schema/ExternalFileField.html > > The syntax Alan suggested tells the solr response writer to generate a > psuedo-field for each doc in the response which contains the results of a > function call -- that function just so happens to be a simple field() > function that returns the numeric value of the specified field name -- > which works for EFF since (as mentioned before) EFF can be used as the > input to any function. > > > -Hoss >
