+1. I think thats the way to go. On Wed, Jul 22, 2009 at 4:25 PM, Michael Busch (JIRA) <j...@apache.org>wrote:
> > [ > https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734296#action_12734296] > > Michael Busch commented on LUCENE-1486: > --------------------------------------- > > I think the best thing to do here is do exactly define what syntax is > supposed to be supported (which Mark H. did in his latest comment), and then > implement the new syntax with the new queryparser. It will enforce correct > syntax and give meaningful exceptions if a query was entered that is not > supported. > > I think we can still reuse big portions of Mark's patch: we should be able > to write a new QueryBuilder that produces the new ComplexPhraseQuery. > > Adriano/Luis: how long would it take to implement? Can we contain it for > 2.9? > > This would mean that these new features would go into contrib in 2.9 as > part of the new query parser framework, and then be moved to core in 3.0. > Also from 3.0 these new features would then be part of Lucene's main query > syntax. Would this makes 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, > junit_complex_phrase_qp_07_22_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 > > -- - Mark http://www.lucidimagination.com
