[ https://issues.apache.org/jira/browse/SOLR-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16580708#comment-16580708 ]
Erick Erickson commented on SOLR-12625: --------------------------------------- Latest iteration, with unit tests (which is what I've been spending most of my time on in the past few days). I'm experimenting with the tests on how easy/difficult it would be to just use the mutable schemas rather than continue the proliferation of schemas, so some of the code in the test may move elsewhere, but in a future JIRA. Not final yet, there are several TODOs and the like. Do note that the unit tests showed some bugs in the optimizer that I fixed. Any feedback welcome. > Combine SolrDocumentFetcher and RetrieveFieldsOptimizer > ------------------------------------------------------- > > Key: SOLR-12625 > URL: https://issues.apache.org/jira/browse/SOLR-12625 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Erick Erickson > Assignee: Erick Erickson > Priority: Major > Attachments: SOLR-12625.patch, SOLR-12625.patch, SOLR-12625.patch > > > 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". > Assigning to myself to keep track, but if anyone feels motivated feel free to > take it over. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org