[
https://issues.apache.org/jira/browse/SOLR-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573982#comment-16573982
]
Erick Erickson commented on SOLR-12625:
---------------------------------------
Thanks for looking at this!
{quote}I think we can do better
{quote}
I sure hope so
{quote}
...Object just feels clumsy to me... The call to {{solrDoc}} would inspect the
SolrReturnFields to see if it has the computed information that is today
present on RetrieveFieldsOptimizer, and if not then compute that...The call to
{{solrDoc}} would inspect the SolrReturnFields to see if it has the computed
information that is today present on RetrieveFieldsOptimizer...
{quote}
Me too. Which is one reason I posted it as a PoC so you could generate better
ideas ;).
docFetcher is in the SolrIndexSearcher and can interleave docs, fetching
different fields. This came to light because one of the tests fetches children
(IIRC) which means there's a different set of fields to be retrieved on
subsequent calls. One of the things I also want to do is write a test that has
multiple threads querying for different field lists to stress this kind of
thing.
Are you thinking of putting the RetrieveFieldsOptimizer in SolrReturnFields and
Moving the class over there?
{quote}Perhaps we could add a boolean to the proposed solrDoc....
{quote}
How about just put the method over in SolrDocument like
{{String[] getValuesAsStrings(fieldName)?}} Seems cleaner.
{quote}Your change to SolrDocument appears purely code formatting; true?
{quote}
Rats. I've been having trouble with my new machine and getting IntelliJ to
really _not_ screw around with lines that haven't been changed, looks like I
have more work to do there. Yep, purely formatting, I'll revert.
Thanks again.
> 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
>
>
> 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
