It makes sense to me! RetrieveFieldsOptimizer feels like more of an internal algorithm class that should not have been exposed outside of SolrDocumentFetcher. I said similarly here: https://issues.apache.org/jira/browse/SOLR-8344?focusedCommentId=16165102&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16165102 Although Dat in the next comment seemed to disagree. Well it's a bit apples 'n oranges... I thought perhaps it could be some static methods and Dat disagreed with that... but even if we have the class, it needn't be so public (i.e. code using SolrDocumentFetcher needn't know it exists)
On Tue, Jul 31, 2018 at 1:08 PM Erick Erickson <[email protected]> wrote: > We have SolrDocumentFetcher and RetrieveFieldsOptimizer. The > relationship between the two is unclear at first glance. Using > SolrDocumentFetcher by itself is (or can be) inefficient. > > WDYT about combining the two? Is there a good reason you would want to > use SolrDocumentFetcher _instead_ of RetrieveFieldsOptimizer? > > Ideally I'd want to be able to write code like: > > solrDocumentFetcher.fillDocValuesMostEfficiently > > That created an optimizer and "did the right thing". > > Is this desirable/possible? Suggestions? Should I raise an improvement > JIRA? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
