Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.6, 4.0-ALPHA
    • Fix Version/s: 3.6, 4.0-ALPHA
    • Component/s: core/search
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      MTQ#getEnum() is protected and in order to access it you need to be in the o.a.l.search package.

      here is a relevant snipped from the mailing list discussion

      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".
      
      1. LUCENE-3789.patch
        2 kB
        Simon Willnauer

        Activity

        Hide
        Simon Willnauer added a comment -

        tiny simple patch against trunk... 3.x'd look slightly different and needs a changes entry to its pretty straight forward though.

        Show
        Simon Willnauer added a comment - tiny simple patch against trunk... 3.x'd look slightly different and needs a changes entry to its pretty straight forward though.
        Hide
        Simon Willnauer added a comment -

        i will go ahead and commit if nobody objects? I will work on a 3.x port once this is in trunk

        Show
        Simon Willnauer added a comment - i will go ahead and commit if nobody objects? I will work on a 3.x port once this is in trunk
        Hide
        Robert Muir added a comment -

        Looks fine to me!

        Show
        Robert Muir added a comment - Looks fine to me!
        Hide
        Uwe Schindler added a comment -

        Looks fine. I would make the access method final.

        Show
        Uwe Schindler added a comment - Looks fine. I would make the access method final.
        Hide
        Simon Willnauer added a comment -

        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...

        Show
        Simon Willnauer added a comment - 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...
        Hide
        Uwe Schindler added a comment -

        OK, I agree. I had a usecase exactly like you said (filtering the termsenum to only collect terms with a low/high docfreq,...). I did this by wrapping MTQ qith the protected problem in another variant. Here you only need a new rewrite method.

        Show
        Uwe Schindler added a comment - OK, I agree. I had a usecase exactly like you said (filtering the termsenum to only collect terms with a low/high docfreq,...). I did this by wrapping MTQ qith the protected problem in another variant. Here you only need a new rewrite method.

          People

          • Assignee:
            Simon Willnauer
            Reporter:
            Simon Willnauer
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development