[
https://issues.apache.org/jira/browse/LUCENE-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964819#action_12964819
]
Robert Muir commented on LUCENE-2784:
-------------------------------------
bq. Looks god, but I think (no tests hit this), that you must do a null check
when calling MultiFields.getTerms().
We need tests for this, and to decide how to handle it: e.g. return
emptytermsenum or whatever is my first idea.
its still better than the empty condition being handled in FTE though (and
checked on every call to next())
bq. We should really remove usage of MultiFields here, all Filters and Queries
now work directly on segment readers.
I agree, we don't need multifields in these queries. (I just did it to be
consistent with trunk).
> Change all FilteredTermsEnum impls into TermsEnum decorators
> ------------------------------------------------------------
>
> Key: LUCENE-2784
> URL: https://issues.apache.org/jira/browse/LUCENE-2784
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Robert Muir
> Assignee: Uwe Schindler
> Fix For: 4.0
>
> Attachments: LUCENE-2784.patch
>
>
> Currently, FilteredTermsEnum has two ctors:
> * FilteredTermsEnum(IndexReader reader, String field)
> * FilteredTermsEnum(TermsEnum tenum)
> But most of our concrete implementations (e.g. TermsRangeEnum) use the
> IndexReader+field ctor
> In my opinion we should remove this ctor, and switch over all
> FilteredTermsEnum implementations to just take a TermsEnum.
> Advantages:
> * This simplifies FilteredTermsEnum and its subclasses, where they are more
> decorator-like (perhaps in the future we could compose them)
> * Removes silly checks such as if (tenum == null) in every next()
> * Allows for consumers to pass in enumerators however they want: e.g. its
> their responsibility if they want to use MultiFields or not, it shouldnt be
> buried in FilteredTermsEnum.
> I created a quick patch (all core+contrib+solr tests pass), but i think this
> opens up more possibilities for refactoring improvements that haven't yet
> been done in the patch: we should explore these too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
