[jira] Created: (LUCENE-1245) MultiFieldQueryParser is not friendly for overriding

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (LUCENE-1245) MultiFieldQueryParser is not friendly for overriding

JIRA jira@apache.org
MultiFieldQueryParser is not friendly for overriding
----------------------------------------------------

                 Key: LUCENE-1245
                 URL: https://issues.apache.org/jira/browse/LUCENE-1245
             Project: Lucene - Java
          Issue Type: Improvement
          Components: QueryParser
    Affects Versions: 2.3.2
            Reporter: Trejkaz


LUCENE-1213 fixed an issue in MultiFieldQueryParser where the slop parameter wasn't being properly applied.  Problem is, the fix which eventually got committed is calling super.getFieldQuery(String,String), bypassing any possibility of customising the query behaviour.

This should be relatively simply fixable by modifying getFieldQuery(String,String,int) to, if field is null, recursively call getFieldQuery(String,String,int) instead of setting the slop itself.  This gives subclasses which override either getFieldQuery method a chance to do something different.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-1245) MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)

JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trejkaz updated LUCENE-1245:
----------------------------

    Lucene Fields: [New, Patch Available]  (was: [New])
          Summary: MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)  (was: MultiFieldQueryParser is not friendly for overriding)

(Updating title to be more specific about what wasn't friendly.)

> MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)
> -------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1245
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1245
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: QueryParser
>    Affects Versions: 2.3.2
>            Reporter: Trejkaz
>
> LUCENE-1213 fixed an issue in MultiFieldQueryParser where the slop parameter wasn't being properly applied.  Problem is, the fix which eventually got committed is calling super.getFieldQuery(String,String), bypassing any possibility of customising the query behaviour.
> This should be relatively simply fixable by modifying getFieldQuery(String,String,int) to, if field is null, recursively call getFieldQuery(String,String,int) instead of setting the slop itself.  This gives subclasses which override either getFieldQuery method a chance to do something different.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LUCENE-1245) MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LUCENE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trejkaz updated LUCENE-1245:
----------------------------

    Attachment: multifield.patch

Fix makes getFieldQuery(String,String) and getFieldQuery(String,String,int) work more or less the same.  Neither calls methods on super and thus overriding the methods will work (and does.  Although I have no unit test for this yet.)

Common boosting logic is extracted to an applyBoost method.  Also the check for the clauses being empty, I have removed... as getBooleanQuery appears to be doing that already.


> MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)
> -------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1245
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1245
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: QueryParser
>    Affects Versions: 2.3.2
>            Reporter: Trejkaz
>         Attachments: multifield.patch
>
>
> LUCENE-1213 fixed an issue in MultiFieldQueryParser where the slop parameter wasn't being properly applied.  Problem is, the fix which eventually got committed is calling super.getFieldQuery(String,String), bypassing any possibility of customising the query behaviour.
> This should be relatively simply fixable by modifying getFieldQuery(String,String,int) to, if field is null, recursively call getFieldQuery(String,String,int) instead of setting the slop itself.  This gives subclasses which override either getFieldQuery method a chance to do something different.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (LUCENE-1245) MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582490#action_12582490 ]

Trejkaz commented on LUCENE-1245:
---------------------------------

Here's an example illustrating the way we were using it, although instead of changing the query text we're actually returning a different query class -- that class isn't in Lucene Core and also it's easier to build up an expected query if it's just a TermQuery.

    public void testOverrideGetFieldQuery() throws Exception {
        String[] fields = { "a", "b" };
        QueryParser parser = new MultiFieldQueryParser(fields, new StandardAnalyzer()) {
            protected Query getFieldQuery(String field, String queryText, int slop) throws ParseException {
                if (field != null && slop == 1) {
                    field = "z" + field;
                }
                return super.getFieldQuery(field, queryText, slop);
            }
        };

        BooleanQuery expected = new BooleanQuery();
        expected.add(new TermQuery(new Term("a", "zabc")), BooleanClause.Occur.SHOULD);
        expected.add(new TermQuery(new Term("b", "zabc")), BooleanClause.Occur.SHOULD);
        assertEquals("Expected a mangled query", expected, parser.parse("\"abc\"~1"));
    }


> MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)
> -------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1245
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1245
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: QueryParser
>    Affects Versions: 2.3.2
>            Reporter: Trejkaz
>         Attachments: multifield.patch
>
>
> LUCENE-1213 fixed an issue in MultiFieldQueryParser where the slop parameter wasn't being properly applied.  Problem is, the fix which eventually got committed is calling super.getFieldQuery(String,String), bypassing any possibility of customising the query behaviour.
> This should be relatively simply fixable by modifying getFieldQuery(String,String,int) to, if field is null, recursively call getFieldQuery(String,String,int) instead of setting the slop itself.  This gives subclasses which override either getFieldQuery method a chance to do something different.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Issue Comment Edited: (LUCENE-1245) MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582490#action_12582490 ]

trejkaz edited comment on LUCENE-1245 at 3/26/08 5:13 PM:
----------------------------------------------------------

Here's an example illustrating the way we were using it, although instead of changing the query text we're actually returning a different query class -- that class isn't in Lucene Core and also it's easier to build up an expected query if it's just a TermQuery.

{noformat}
    public void testOverrideGetFieldQuery() throws Exception {
        String[] fields = { "a", "b" };
        QueryParser parser = new MultiFieldQueryParser(fields, new StandardAnalyzer()) {
            protected Query getFieldQuery(String field, String queryText, int slop) throws ParseException {
                if (field != null && slop == 1) {
                    field = "z" + field;
                }
                return super.getFieldQuery(field, queryText, slop);
            }
        };

        BooleanQuery expected = new BooleanQuery();
        expected.add(new TermQuery(new Term("a", "zabc")), BooleanClause.Occur.SHOULD);
        expected.add(new TermQuery(new Term("b", "zabc")), BooleanClause.Occur.SHOULD);
        assertEquals("Expected a mangled query", expected, parser.parse("\"abc\"~1"));
    }
{noformat}


      was (Author: trejkaz):
    Here's an example illustrating the way we were using it, although instead of changing the query text we're actually returning a different query class -- that class isn't in Lucene Core and also it's easier to build up an expected query if it's just a TermQuery.

    public void testOverrideGetFieldQuery() throws Exception {
        String[] fields = { "a", "b" };
        QueryParser parser = new MultiFieldQueryParser(fields, new StandardAnalyzer()) {
            protected Query getFieldQuery(String field, String queryText, int slop) throws ParseException {
                if (field != null && slop == 1) {
                    field = "z" + field;
                }
                return super.getFieldQuery(field, queryText, slop);
            }
        };

        BooleanQuery expected = new BooleanQuery();
        expected.add(new TermQuery(new Term("a", "zabc")), BooleanClause.Occur.SHOULD);
        expected.add(new TermQuery(new Term("b", "zabc")), BooleanClause.Occur.SHOULD);
        assertEquals("Expected a mangled query", expected, parser.parse("\"abc\"~1"));
    }

 

> MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)
> -------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1245
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1245
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: QueryParser
>    Affects Versions: 2.3.2
>            Reporter: Trejkaz
>         Attachments: multifield.patch
>
>
> LUCENE-1213 fixed an issue in MultiFieldQueryParser where the slop parameter wasn't being properly applied.  Problem is, the fix which eventually got committed is calling super.getFieldQuery(String,String), bypassing any possibility of customising the query behaviour.
> This should be relatively simply fixable by modifying getFieldQuery(String,String,int) to, if field is null, recursively call getFieldQuery(String,String,int) instead of setting the slop itself.  This gives subclasses which override either getFieldQuery method a chance to do something different.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[jira] Issue Comment Edited: (LUCENE-1245) MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/LUCENE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582490#action_12582490 ]

trejkaz edited comment on LUCENE-1245 at 3/26/08 5:32 PM:
----------------------------------------------------------

Here's an example illustrating the way we were using it, although instead of changing the query text we're actually returning a different query class -- that class isn't in Lucene Core and also it's easier to build up an expected query if it's just a TermQuery.

{noformat}
    public void testOverrideGetFieldQuery() throws Exception {
        String[] fields = { "a", "b" };
        QueryParser parser = new MultiFieldQueryParser(fields, new StandardAnalyzer()) {
            protected Query getFieldQuery(String field, String queryText, int slop) throws ParseException {
                if (field != null && slop == 1) {
                    queryText = "z" + queryText;
                }
                return super.getFieldQuery(field, queryText, slop);
            }
        };

        BooleanQuery expected = new BooleanQuery();
        expected.add(new TermQuery(new Term("a", "zabc")), BooleanClause.Occur.SHOULD);
        expected.add(new TermQuery(new Term("b", "zabc")), BooleanClause.Occur.SHOULD);
        assertEquals("Expected a mangled query", expected, parser.parse("\"abc\"~1"));
    }
{noformat}


      was (Author: trejkaz):
    Here's an example illustrating the way we were using it, although instead of changing the query text we're actually returning a different query class -- that class isn't in Lucene Core and also it's easier to build up an expected query if it's just a TermQuery.

{noformat}
    public void testOverrideGetFieldQuery() throws Exception {
        String[] fields = { "a", "b" };
        QueryParser parser = new MultiFieldQueryParser(fields, new StandardAnalyzer()) {
            protected Query getFieldQuery(String field, String queryText, int slop) throws ParseException {
                if (field != null && slop == 1) {
                    field = "z" + field;
                }
                return super.getFieldQuery(field, queryText, slop);
            }
        };

        BooleanQuery expected = new BooleanQuery();
        expected.add(new TermQuery(new Term("a", "zabc")), BooleanClause.Occur.SHOULD);
        expected.add(new TermQuery(new Term("b", "zabc")), BooleanClause.Occur.SHOULD);
        assertEquals("Expected a mangled query", expected, parser.parse("\"abc\"~1"));
    }
{noformat}

 

> MultiFieldQueryParser is not friendly for overriding getFieldQuery(String,String,int)
> -------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1245
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1245
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: QueryParser
>    Affects Versions: 2.3.2
>            Reporter: Trejkaz
>         Attachments: multifield.patch
>
>
> LUCENE-1213 fixed an issue in MultiFieldQueryParser where the slop parameter wasn't being properly applied.  Problem is, the fix which eventually got committed is calling super.getFieldQuery(String,String), bypassing any possibility of customising the query behaviour.
> This should be relatively simply fixable by modifying getFieldQuery(String,String,int) to, if field is null, recursively call getFieldQuery(String,String,int) instead of setting the slop itself.  This gives subclasses which override either getFieldQuery method a chance to do something different.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]