[
https://issues.apache.org/jira/browse/SOLR-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574271#comment-16574271
]
David Smiley commented on SOLR-12625:
-------------------------------------
bq. 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.
Interesting; which test is this? Per chance TestChildDocTransformer? Any way,
I don't imagine this would be a problem since if you want different fields for
children, then you could simply use a different SolrReturnFields, and so
there's no mismatch.
bq. Are you thinking of putting the RetrieveFieldsOptimizer in SolrReturnFields
and Moving the class over there?
I didn't completely think that through yet. Eh... it's debatable. It'd be
nice if SolrReturnFields didn't itself have to reference anything in
SolrDocumentFetcher since that would create a bidirectional reference which I'd
like to avoid as a matter of design taste. So therefore I think most of the
decision logic should go in SolrDocumentFetcher in some form. I've always
found SolrReturnFields to be a bit confusing so I don't love adding stuff to
make it more complex but if these two field lists are clearly documented (to
include when and who sets them) then it's okay I think. Maybe names like
"fetchStoredFields" and "fetchDocValueFields".
bq. How about just put the method over in SolrDocument like {{String[]
getValuesAsStrings(fieldName)}}? Seems cleaner.
First, why just Strings when the type might be something else like a Date? So
there's that. Then... I don't really like values like Lucene IndexableField
winding up as-is on a SolrDocument. It's a SolrDocument, not a Lucene
Document. But I understand the motivation: it was *a* way (though not the only
possible way) to have lazy loading as late as possible. But this has led to
some clumsy gotchas with consumers needing to be aware they have to deal with
this Lucene IndexableField value when they just want a String (or a Date etc.).
I bet the lazy load aspect might be better implemented as another subclass of
SolrDocument or in SolrDocument itself, so that the caller doesn't have to even
be aware. But that seems out of scope of this issue. My proposed boolean flag
would be minor enough, though.
> 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: [email protected]
For additional commands, e-mail: [email protected]
