lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3789) Expose FilteredTermsEnum from MTQ
Date Sat, 18 Feb 2012 21:07:59 GMT


Simon Willnauer commented on LUCENE-3789:

bq. Looks fine. I would make the access method final.

well, I actually didn't make this final on purpose. if you want to filter the enum used for
rewriting you can now simply override and call super.getTermsEnum(...) otherwise you need
to subclass all MTQ you want to filter and change QParsers etc. that way we can simply subclass
one rewrite method and we are good to go. I have a usecase where I drop terms based on their
DF so this would make this much easier...

> Expose FilteredTermsEnum from MTQ 
> ----------------------------------
>                 Key: LUCENE-3789
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/search
>    Affects Versions: 3.6, 4.0
>            Reporter: Simon Willnauer
>            Priority: Minor
>             Fix For: 3.6, 4.0
>         Attachments: LUCENE-3789.patch
> MTQ#getEnum() is protected and in order to access it you need to be in the
> here is a relevant snipped from the mailing list discussion
> {noformat}
> getEnum() is protected so it is intended to be called *only* by subclasses (that's the
idea behind protected methods). They are also accessible by other classes from the same package,
but that's more a Java bug than a feature. The problem with MTQ is that RewriteMethod is a
separate *class* and *not a subclass* of MTQ, so the method cannot be called (it can because
of the "java bug" called from same package). So theoretically it has to be public otherwise
you cannot call getEnum().
> Another cleaner fix would be to add a protected final method to RewriteMethod that calls
this method from MTQ. So anything subclassing RewriteMethod can get the enum from inside the
RewriteMethod class which is the "correct" way to handle it. Delegating to MTQ is then "internal".
> {noformat}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message