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

Michael Busch commented on LUCENE-1486:
---------------------------------------

{quote}
It only supports a limited subset of the Lucene query language - perhaps we 
could improve the exceptions being thrown, but the exceptions the queryparser 
throws often leave just as much to be desired. I don't think its experimental 
because of that.
{quote}

Because it only supports a limited subset of the language, I feel like we could 
have taken a different approach here? Why not add the features that are 
supported and make sense to the main query parser? 

The documentation does not tell me what is supported and what is not currently. 
And looking through the code some methods now throw RuntimeExceptions, because 
the overridden methods themselves don't throw anything. These things feel a bit 
unfinished. 

I'm not saying these issues are not fixable. But maybe we should rethink the 
design. My biggest concern is that this new parser doesn't seem to have a 
well-defined syntax. So since it doesn't check if a query is actually valid or 
not, it might be hard to maintain. E.g. if you add new language features to the 
main QP, it's currently not defined what will happen if you use them with this 
one.

That's why I'm proposing to move it to contrib and mark it as experimental. 
Then we have more time to decide if the approach of adding the new features to 
the main QP makes more sense. 

> Wildcards, ORs etc inside Phrase queries
> ----------------------------------------
>
>                 Key: LUCENE-1486
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1486
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: QueryParser
>    Affects Versions: 2.4
>            Reporter: Mark Harwood
>            Assignee: Mark Harwood
>            Priority: Minor
>             Fix For: 2.9
>
>         Attachments: ComplexPhraseQueryParser.java, 
> junit_complex_phrase_qp_07_21_2009.patch, LUCENE-1486.patch, 
> LUCENE-1486.patch, LUCENE-1486.patch, LUCENE-1486.patch, 
> TestComplexPhraseQuery.java
>
>
> An extension to the default QueryParser that overrides the parsing of 
> PhraseQueries to allow more complex syntax e.g. wildcards in phrase queries.
> The implementation feels a little hacky - this is arguably better handled in 
> QueryParser itself. This works as a proof of concept  for much of the query 
> parser syntax. Examples from the Junit test include:
>               checkMatches("\"j*   smyth~\"", "1,2"); //wildcards and fuzzies 
> are OK in phrases
>               checkMatches("\"(jo* -john)  smith\"", "2"); // boolean logic 
> works
>               checkMatches("\"jo*  smith\"~2", "1,2,3"); // position logic 
> works.
>               
>               checkBadQuery("\"jo*  id:1 smith\""); //mixing fields in a 
> phrase is bad
>               checkBadQuery("\"jo* \"smith\" \""); //phrases inside phrases 
> is bad
>               checkBadQuery("\"jo* [sma TO smZ]\" \""); //range queries 
> inside phrases not supported
> Code plus Junit test to follow...

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to