[
https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036364#comment-14036364
]
Paul Elschot commented on LUCENE-5205:
--------------------------------------
I cannot create branches in the main svn, we can work via github because that
is integrated with issues.apache.org for lucene here.
One possible plan is to start from a merge between lucene5205 and recent trunk,
and then add the positional joins there.
(To locally see the branches available for tracking from upstream, use "git
ls-remote upstream". To keep an overview of different local branches "gitk" has
become indispensable for me.)
I ran into a few small issues when merging the lucene5205 branch and a recent
trunk (see above), so perhaps you can merge them in your local git repo first,
resolve the conflicts, and then push that to your github repo.
That fits nicely at this issue, so you could create a pull request for that at
this issue by mentioning LUCENE-5205 early in the pull request message.
I have a field schema and a query factory more or less ready to be added to the
positional joins. It should be possible to use these in the extended query
parser. I'll push these additions to my github repo, and I'll add a pull
request for that at LUCENE-5627.
>From that point we can use LUCENE-5758, use your github repo and/or mine (git
>is distributed), and we can communicate with github pull requests and/or with
>comments and patches at LUCENE-5758.
I normally do small commits locally (with "git gui&") and prepare these for
pushing to github by using the squash option to git merge (from the command
line, starting at a new branch at a trunk commit, and merging from the local
feature branch that has the same trunk commit merged into it).
This squashing is quite similar to preparing a larger patch, and "git diff
--stat" works nicely to check what is going on.
It might be good to base our pull requests on the same trunk commit, we'll see.
There may be easier ways to use git/github for this, in case someone knows one
please let us know.
> [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to
> classic QueryParser
> -----------------------------------------------------------------------------------------------
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/queryparser
> Reporter: Tim Allison
> Labels: patch
> Fix For: 4.9
>
> Attachments: LUCENE-5205-cleanup-tests.patch,
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz,
> LUCENE-5205_dateTestReInitPkgPrvt.patch,
> LUCENE-5205_improve_stop_word_handling.patch,
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch,
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator:
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta
> apache\]~3 lucene\]\~>4 ::
> find "jakarta" within 3 words of "apache", and that hit has to be within
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in:
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two
> words of "ap*che" and that hit has to be within ten words of something like
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1,
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317
> and LUCENE-5318) and for analytical search.
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome. Thank you.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
