Lucene - Core
  1. Lucene - Core
  2. LUCENE-1819

MatchAllDocsQuery.toString(String field) does not honor the javadoc contract

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.4.1
    • Fix Version/s: 2.9
    • Component/s: core/search
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      Should be

      public String toString(String field)

      { return "*:*"; }

      QueryParser needs to be able to parse the String form of this query.

        Activity

        Hide
        Mark Miller added a comment -

        I agree - thanks John.

        Show
        Mark Miller added a comment - I agree - thanks John.
        Hide
        Mark Miller added a comment -

        unless someone has an objection, I'm going to commit this in a day or two.

        Show
        Mark Miller added a comment - unless someone has an objection, I'm going to commit this in a day or two.
        Hide
        Mark Miller added a comment -

        Thats funny - I didn't realize you originally donated this back in 05 - 4 years later, almost to the day (it was committed August 21st), you are back to correct the parsable toString.

        Thats interesting stuff.

        Show
        Mark Miller added a comment - Thats funny - I didn't realize you originally donated this back in 05 - 4 years later, almost to the day (it was committed August 21st), you are back to correct the parsable toString. Thats interesting stuff.
        Hide
        John Wang added a comment -

        Thanks Mark for taking care of this issue!
        w.r.t. this class, funny coincidence

        What are you thoughts about QueryParser being able to know about custom Query implementations? E.g. if I were to write a MyQuery class and implemen the toString method a certain way, how would QueryParser know about MyQuery? Is it possible to extend QueryParser?

        Show
        John Wang added a comment - Thanks Mark for taking care of this issue! w.r.t. this class, funny coincidence What are you thoughts about QueryParser being able to know about custom Query implementations? E.g. if I were to write a MyQuery class and implemen the toString method a certain way, how would QueryParser know about MyQuery? Is it possible to extend QueryParser?
        Hide
        Mark Miller added a comment -

        What are you thoughts about QueryParser being able to know about custom Query implementations? E.g. if I were to write a MyQuery class and implemen the toString method a certain way, how would QueryParser know about MyQuery?

        Right - this has always been a limitation. That is why the wording has been loosened a lot of the years in Query.toString(). There is really not a lot you can do here - non of the SpanQuerys produce parsable toStrings because there is no support for SpanQuerys in the QueryParser. I think a couple others do not work either. I think its just got to be something we live with - you simply can't count on it - but if possible, its nice I guess - especially for the core queries.

        Is it possible to extend QueryParser?

        Its possible to extend it, but not really syntax wise. The new QueryParser in contrib will likely be more extensable in that regard in a way - though still you would be building another parser - it would just hopefully allow for a lot of non cut and paste reuse if you just want to add syntax (I think - I'm only at the surface with the new QP).

        Overall though, its not really a contract, because its not something users can adhere to. Its more of an internal nicety suggestion - but if your not a Query already in the QP, your out of luck anyway - at best you could toString to a primitive query parsable String if your custom query rewrites to primitives.

        Show
        Mark Miller added a comment - What are you thoughts about QueryParser being able to know about custom Query implementations? E.g. if I were to write a MyQuery class and implemen the toString method a certain way, how would QueryParser know about MyQuery? Right - this has always been a limitation. That is why the wording has been loosened a lot of the years in Query.toString(). There is really not a lot you can do here - non of the SpanQuerys produce parsable toStrings because there is no support for SpanQuerys in the QueryParser. I think a couple others do not work either. I think its just got to be something we live with - you simply can't count on it - but if possible, its nice I guess - especially for the core queries. Is it possible to extend QueryParser? Its possible to extend it, but not really syntax wise. The new QueryParser in contrib will likely be more extensable in that regard in a way - though still you would be building another parser - it would just hopefully allow for a lot of non cut and paste reuse if you just want to add syntax (I think - I'm only at the surface with the new QP). Overall though, its not really a contract, because its not something users can adhere to. Its more of an internal nicety suggestion - but if your not a Query already in the QP, your out of luck anyway - at best you could toString to a primitive query parsable String if your custom query rewrites to primitives.
        Hide
        Yonik Seeley added a comment -

        it would just hopefully allow for a lot of non cut and paste reuse if you just want to add syntax

        But the new query parser still uses the JavaCC grammar... so the most difficult part of adding new syntax (by far IMO) is unchanged.

        Show
        Yonik Seeley added a comment - it would just hopefully allow for a lot of non cut and paste reuse if you just want to add syntax But the new query parser still uses the JavaCC grammar... so the most difficult part of adding new syntax (by far IMO) is unchanged.
        Hide
        Mark Miller added a comment -

        Thanks John!

        Show
        Mark Miller added a comment - Thanks John!

          People

          • Assignee:
            Mark Miller
            Reporter:
            John Wang
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development