[
https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736965#action_12736965
]
Luis Alves commented on LUCENE-1486:
------------------------------------
My understanding is that with "New flexible query parser" (LUCENE-1567),
the old QueryParser classes will be deprecated in 2.9
and removed in 3.0 (or moved to contrib in 3.0).
This change will also make ComplexPhraseQueryParser deprecated
because it currently extends the old queryparser.
ComplexPhraseQueryParser was not part of any lucene release
and was only checked in 2 months ago in trunk.
For the reasons above I think we should re-implement this functionality
using the new flexible query parser.
3.0 and 2.9 releases will be very similar
but 3.0 will have all deprecated APIs removed (at least this is my
understanding).
In my view the path should be:
- Wait for LUCENE-1567 to be in trunk
- re-implement this feature using the "New flexible query parser"
- and probably do it using a super set of the current syntax with a new
TextParser.
I'm not sure if I'll have the time to implement a compatible implementation of
ComplexPhraseQueryParser before 2.9 release :(
I'm currently working on 1567 to finalize the patch,
cleaning up javadocs and some small clean up to the APIs.
I'll try to work on ComplexPhraseQueryParser,
once lucene-1567 is in the trunk.
So in my view, ComplexPhraseQueryParser depends on 1567,
and will require some extra work after 1567 is in the trunk.
I think we have the following, options:
# We could wait until 1567 is in trunk and wait for a compatible implementation
of ComplexPhraseQueryParser using 1567,
before we release 2.9. (this would still remove the current
ComplexPhraseQueryParser class, and provide this features with
LuceneQueryParserHelper class, or with a new TextParser name complexphrase)
# We can release 2.9 with only 1567, but that will require
ComplexPhraseQueryParser to be removed from trunk or at least deprecated in
2.9, and in 3.X re-implement it using the "New flexible query parser" APIs
I hope this helps :)
> 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 non default
> field.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
