This would require some storage when the index is built to map between the internal field name and the "display name" ... since this is not a Lucene concept it would have to be a higher level concept hat Solr write to disk directly -- there are currently no concepts like this but that doens't mean there can't be.
the question becomes: "Is this the type of data that Solr *should* store?" ... in my opinion the answer is no. I can't think of any value add in having Solr keep track of the fact that "ds" means "Download Speed" vs having an external data mapping keep track of that information, since direct access to that info inside of Solr wouldn't typically make the performance of requests any faster or reduce the size of the responses, it seems like the type of data that make more senese to maintain externally. as to your specific situation... : I would normally agree but the problem is that I'm making very heavy use : of the dynamic fields and therefore don't really know what a record : looks like. Ie the only thing that knows about the data is the input : data itself. I've added logic to 'solrify' the input field names as : they come to me in the "Download Speed" format but making the reverse : happen is impossible from the client side because each record is : different. ...if every document is truely differnet, then the "ds" field for one doc may not be the same as the "ds" field for another doc ... which makes it sound like hte field display names themselves are document specific 'data' that should be stored as field values. I have a lot of personal experience with an app (the first Solr app actually) where the dynamic fields a doc has depend on it's category, and i actually put the info about the fields (including their display names and info on how to facet on them) into stored fields special "metadata documents" which go into the index and then a custom request handler first says "what category am i interested in?" to find the relevant metadata doc, and then uses the info found in that doc to both query the index for the "real" results, as well as to return the "display" values for all of the important fields. if you can particion your index in this way, then similar metadata docs might mke sense for you ... if you can't (becuase every doc turely is differnet) then making the "real" documents also store the "metadata" about field names can work just as well. -Hoss
