First off: it seems like you are massively missunderstanding the point of ExternalFileField ... the reason it only supports "float" as a base type is because it's purpose is to allow people to have an external file provide float values in ValueSource calculations (ie: you can have a popularity.txt file that you update hourly without needing to reindex all of your popular documents).
The values from the external files can't be included in the response. : We have seen that size of the index has a direct impact on the search speed, : especially when the index size is in GBs, so trying all possible ways to keep : the index size as low as we can. while that's generally true, it tends to follow from the index size increasing as a result of the number of docs / number of indexed terms increasing. if you keep the quanity of "indexed" data the same, and only increase the quantity of stored field data you should see the search speed remaining (roughly) the same. even if you're hunch is correct about the advantages of using an external field (and i don't think it is) ... : Here's what we were planning: initially, all the fields except the : solr.ExternalFileField type field will be queried and will be displayed to the : end user. . There will be subsequent calls from the UI to pull the : solr.ExternalFileField field that will be loaded in a lazy manner. ...if this is the usage pattern you expect, there's really no need for the "external" file bsaed data to be returned by solr ... the uniqueKey field you use in solr could be used store thta data in any data repository (DB, flat files, hbase, etc...) and then a completley seperate server (DB, HTTP, hbase-thrift, etc...) could be used to fetch the external data. -Hoss
