Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-796

Change Visibility of fields[] in MultiFieldQueryParser

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: 2.2
    • Component/s: core/queryparser
    • Labels:
      None
    • Environment:

      not important

      Description

      In MultiFieldQueryParser the two methods

      protected Query getFuzzyQuery(String field, String termStr, float minSimilarity) throws ParseException
      protected Query getWildcardQuery(String field, String termStr) throws ParseException

      are intended to be overwritten if one would like to avoid fuzzy and wildcard queries. However, the String[] fields attribute of this class is private and hence it is not accessible in subclasses of MFQParser. If you just change it to protected this issue should be solved.

      1. LUCENE-796.txt
        2 kB
        Steven Parkes

        Activity

        Hide
        steven_parkes Steven Parkes added a comment -

        This code is a little bit twisted; took me a while to figure out how it was working.

        I'm wondering what you want to do with the variables if they're available ... not that I'm terribly against making them protected (or adding gettter/setters), but I see another issue here.

        The code right now takes two paths: if you pass a field, it just calls QP via super. If you don't pass a field, it loops through each of the fields it has, which I suspect is usually what one wants. But in this loop, it also calls super, which means you don't get a chance in your derived class to override it again. I think it would make more sense to not call super in the loop case. So derived classes can get access to the call both when no field is passed and when each field is passed.

        Out of curiosity, would this do anything for you? If these were to be made protected, would you just be writing the loop yourself?

        Show
        steven_parkes Steven Parkes added a comment - This code is a little bit twisted; took me a while to figure out how it was working. I'm wondering what you want to do with the variables if they're available ... not that I'm terribly against making them protected (or adding gettter/setters), but I see another issue here. The code right now takes two paths: if you pass a field, it just calls QP via super. If you don't pass a field, it loops through each of the fields it has, which I suspect is usually what one wants. But in this loop, it also calls super, which means you don't get a chance in your derived class to override it again. I think it would make more sense to not call super in the loop case. So derived classes can get access to the call both when no field is passed and when each field is passed. Out of curiosity, would this do anything for you? If these were to be made protected, would you just be writing the loop yourself?
        Hide
        steven_parkes Steven Parkes added a comment -

        This patch allows the recursive per-field calls in MFQP to be overridden by not forcing them to super.

        All tests pass.

        Show
        steven_parkes Steven Parkes added a comment - This patch allows the recursive per-field calls in MFQP to be overridden by not forcing them to super. All tests pass.
        Hide
        otis Otis Gospodnetic added a comment -

        Makes sense. Thanks Steve, applied. I left those 2 private attributes of MFQP as private until somebody asks for them to be protected.

        Show
        otis Otis Gospodnetic added a comment - Makes sense. Thanks Steve, applied. I left those 2 private attributes of MFQP as private until somebody asks for them to be protected.

          People

          • Assignee:
            Unassigned
            Reporter:
            ohummel Oliver Hummel
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development