[
https://issues.apache.org/jira/browse/LUCENE-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734337#action_12734337
]
Mark Harwood commented on LUCENE-1486:
--------------------------------------
bq. I think it's not a big deal, but I'm just trying to understand and raise a
probable wrong test.
Granted, the test fails for a reason other than the one for which I wanted it
to fail.
We can probably strike the test and leave a note saying phrase-within-a-phrase
just does not make sense and is not supported.
bq. Is the operator between 'query' and 'parser' the implicit AND_NEXT_TO or
the default boolean operator (usually OR)?
In brackets it's an OR - the brackets are used to suggest that the current
phrase element at position X is composed of some choices that are evaluated as
a subclause in the same way that in normal query logic sub-clauses are defined
in brackets e.g. +a +(b OR c). There seems to be a reasonable logic to this.
Ideally the ComplexPhraseQueryParser should explicitly turn this setting on
while evaluating the bracketed innards of phrases just in case the base class
has AND as the default.
bq. Mark H, can you please elaborate more on the these other operators "+" "-"
"^" "AND" "&&" "||" "NOT" "!" ":" "[" "]" "{" "}".
OK I'll try and deal with them one by one but these are not necessarily
definitive answers or guarantees of correctly implemented support
OR,||,+, AND, && ..... ignored. The implicit operator is AND_NEXT_TO apart from
in bracketed sections where all elements at this level are ORed
^ .....boosts are carried through from TermQuerys to SpanTermQuerys
NOT, ! ....Creates SpanNotQueries
[]{} ....range queries are supported as are wildcards *, fuzzies ~, ?
bq. query: '(john OR jonathon) smith~0.3 order*' order:sell "stock market"
I'll post the XML query syntax equivalent of what should be parsed here shortly
(just seen your next comment come in)
> 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
