Lucene - Core
  1. Lucene - Core
  2. LUCENE-5261

add simple API to build queries from analysis chain

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.6, Trunk
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Currently this is pretty crazy stuff.

      Additionally its duplicated in like 3 or 4 places in our codebase (i noticed it doing LUCENE-5259)

      We can solve that duplication, and make it easy to simply create queries from an analyzer (its been asked on the user list), as well as make it easier to build new queryparsers.

      1. LUCENE-5261.patch
        63 kB
        Robert Muir
      2. LUCENE-5261.patch
        79 kB
        Robert Muir
      3. LUCENE-5261.patch
        75 kB
        Robert Muir

        Activity

        Hide
        Robert Muir added a comment -

        Simple patch (most of it is removing duplicate crap).

        Example usage:

        QueryBuilder builder = new QueryBuilder(analyzer);
        Query a = builder.createBooleanQuery("body", "just a test");
        Query b = builder.createPhraseQuery("body", "another test");
        
        Show
        Robert Muir added a comment - Simple patch (most of it is removing duplicate crap). Example usage: QueryBuilder builder = new QueryBuilder(analyzer); Query a = builder.createBooleanQuery( "body" , "just a test" ); Query b = builder.createPhraseQuery( "body" , "another test" );
        Hide
        Uwe Schindler added a comment -

        +1 This is really needed. It is very hard to create, e.g., a PhraseQuery from a simple text string. This solves the problem!

        Show
        Uwe Schindler added a comment - +1 This is really needed. It is very hard to create, e.g., a PhraseQuery from a simple text string. This solves the problem!
        Hide
        Dawid Weiss added a comment -

        Pretty cool. +1.

        Show
        Dawid Weiss added a comment - Pretty cool. +1.
        Hide
        Tommaso Teofili added a comment -

        great! +1

        Show
        Tommaso Teofili added a comment - great! +1
        Hide
        Uwe Schindler added a comment -

        Hi, I have one suggestion:
        In ElasticSearch, but also in Solr, you have the option to have a "percentage" minShouldMatch. Currently the same code is duplicated, too. Of course you could do this after the build of the BooleanQuery (just set minShouldMatch depended on clauses().size()), but maybe we can automatically expand the percentage dependend on number of terms. It's just an idea, but also required quite often.

        On the other hand its simple to do:

        float frac =.5f;
        BooleanQuery bq = builder.createBooleanQuery("body", "just a test");
        bq.setMinimumNumberShouldMatch((int) (frac * bq.clauses().size()));
        

        Maybe its not worth to do it...

        Show
        Uwe Schindler added a comment - Hi, I have one suggestion: In ElasticSearch, but also in Solr, you have the option to have a "percentage" minShouldMatch. Currently the same code is duplicated, too. Of course you could do this after the build of the BooleanQuery (just set minShouldMatch depended on clauses().size()), but maybe we can automatically expand the percentage dependend on number of terms. It's just an idea, but also required quite often. On the other hand its simple to do: float frac =.5f; BooleanQuery bq = builder.createBooleanQuery( "body" , "just a test" ); bq.setMinimumNumberShouldMatch(( int ) (frac * bq.clauses().size())); Maybe its not worth to do it...
        Hide
        Robert Muir added a comment -

        I updated the patch with the minShouldMatch.

        Show
        Robert Muir added a comment - I updated the patch with the minShouldMatch.
        Hide
        Uwe Schindler added a comment -

        Nice!

        Show
        Uwe Schindler added a comment - Nice!
        Hide
        David Smiley added a comment -

        Nice!
        Curious, why the removal of

        public static enum Operator { OR, AND }
        
        Show
        David Smiley added a comment - Nice! Curious, why the removal of public static enum Operator { OR, AND }
        Hide
        Robert Muir added a comment -

        Its not removed, just moved. See the patch.

        Show
        Robert Muir added a comment - Its not removed, just moved. See the patch.
        Hide
        Yonik Seeley added a comment -

        This removes a lot of Solr code... are we absolutely sure that there are no changes of behavior lurking?

        Show
        Yonik Seeley added a comment - This removes a lot of Solr code... are we absolutely sure that there are no changes of behavior lurking?
        Hide
        Robert Muir added a comment -

        Yes, its all the same because this code was copied from the lucene queryparser.

        All tests pass.

        Show
        Robert Muir added a comment - Yes, its all the same because this code was copied from the lucene queryparser. All tests pass.
        Hide
        Michael McCandless added a comment -

        +1, patch looks great. This will make it much easier for apps to build their own custom query parsing logic ...

        Show
        Michael McCandless added a comment - +1, patch looks great. This will make it much easier for apps to build their own custom query parsing logic ...
        Hide
        Uwe Schindler added a comment -

        Yonik: If you check the code, you will see that the code added to the new class is almost identical to the one removed at several places, only some cosmetic changes. This is because it was a clone already! This is just a refactoring. If the code would be different, it would have been a bug

        From my quick check, I see no differences.

        Show
        Uwe Schindler added a comment - Yonik: If you check the code, you will see that the code added to the new class is almost identical to the one removed at several places, only some cosmetic changes. This is because it was a clone already! This is just a refactoring. If the code would be different, it would have been a bug From my quick check, I see no differences.
        Hide
        Yonik Seeley added a comment -

        only some cosmetic changes.

        OK, thanks - it was tough for me to tell by just visual inspection.

        Show
        Yonik Seeley added a comment - only some cosmetic changes. OK, thanks - it was tough for me to tell by just visual inspection.
        Hide
        Robert Muir added a comment -

        Simplified patch:

        • I removed get/set defaultOperator and slop, restoring these to the QPs (so less changes there: including no api impact)
        • I removed operator enum completely and just use Occur for that.
        • instead createFieldQuery just takes Occur and slop as parameters.
        • added javadocs

        From the "use directly" side I just added createBooleanQuery(String,String,Occur) and createPhraseQuery(String,String,int).

        I think this is much more intuitive, these parameters are really "per-query" anyway: they shouldnt be getters/setters on this class. (Thats just brain damage from our crazy QP).

        I think this is ready.

        Show
        Robert Muir added a comment - Simplified patch: I removed get/set defaultOperator and slop, restoring these to the QPs (so less changes there: including no api impact) I removed operator enum completely and just use Occur for that. instead createFieldQuery just takes Occur and slop as parameters. added javadocs From the "use directly" side I just added createBooleanQuery(String,String,Occur) and createPhraseQuery(String,String,int). I think this is much more intuitive, these parameters are really "per-query" anyway: they shouldnt be getters/setters on this class. (Thats just brain damage from our crazy QP). I think this is ready.
        Hide
        ASF subversion and git services added a comment -

        Commit 1530693 from Robert Muir in branch 'dev/trunk'
        [ https://svn.apache.org/r1530693 ]

        LUCENE-5261: add simple API to build queries from analysis chain

        Show
        ASF subversion and git services added a comment - Commit 1530693 from Robert Muir in branch 'dev/trunk' [ https://svn.apache.org/r1530693 ] LUCENE-5261 : add simple API to build queries from analysis chain
        Hide
        ASF subversion and git services added a comment -

        Commit 1530701 from Robert Muir in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1530701 ]

        LUCENE-5261: add simple API to build queries from analysis chain

        Show
        ASF subversion and git services added a comment - Commit 1530701 from Robert Muir in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1530701 ] LUCENE-5261 : add simple API to build queries from analysis chain

          People

          • Assignee:
            Unassigned
            Reporter:
            Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development