[
https://issues.apache.org/jira/browse/LUCENE-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley reassigned LUCENE-6513:
------------------------------------
Assignee: David Smiley
Attachment: LUCENE-6513.patch
Here's an updated patch from the most recent one. I made small modifications
to bring it up to date with master, and I added a bunch of nocommits at spots
as reminders to ask questions here in JIRA, but most aren't so much true
nocommits (most are not a blocker to me).
Comments about existing stuff:
* TopTermsRewrite: Why does this sort the terms before looping and calling
addClause?
https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/TopTermsRewrite.java#L159
It's not a big deal but it's not clear what's the point. It appears that
addClause, currently having no javadocs, ought to state that it is called in
term order if it does matter. [~thetaphi] thought you might know as you added
this code. The test
org.apache.lucene.search.TestMultiTermQueryRewrites#testRewritesWithDuplicateTerms
expressly tests that the terms are in order.
* SpanMultiTermQueryWrapper: shouldn't equals() consider the rewrite method?
* SpanMultiTermQueryWrapper: suggest deprecate/removing
setRewriteMethod(SpanRewriteMethod) and doing the same to the referenced inner
class SpanRewriteMethod. getRewriteMethod can return
MultiTermQuery.RewriteMethod. In short, we don't need a typed SpanQuery
derivative of RewriteMethod. It's a bit limiting; it means we can't have an
impl that subclasses another RewriteMethod like ScoringRewrite. Also the
setter makes it mutable but I don't think we want mutable Query subclasses
anymore.
New stuff:
* SpanQueryFrequentTermsScoringRewrite: should perhaps be an inner class of
SpanMultiTermQueryWrapper like some of the existing ones?
* SpanQueryFrequentTermsScoringRewrite: does it matter if the SpanOrQuery we
build has it's SpanTermQuery clauses in lexicographic order or not? This kinda
gets at my Q earlier about TopTermsRewrite sorting.
* FrequentTermsScoringRewrite: probably needs equals & hashcode? Reference
equality will have to do for the pluggable BiPredicate.
* FrequentTermsScoringRewrite.ScoreTerm we could remove this if SpanTermQuery
had getTermStates() like how TermQuery now has this method -- LUCENE-8379.
> Allow limits on SpanMultiTermQueryWrapper expansion
> ---------------------------------------------------
>
> Key: LUCENE-6513
> URL: https://issues.apache.org/jira/browse/LUCENE-6513
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Alan Woodward
> Assignee: David Smiley
> Priority: Minor
> Attachments: LUCENE-6513.patch, LUCENE-6513.patch, LUCENE-6513.patch,
> LUCENE-6513.patch, LUCENE-6513.patch
>
>
> SpanMultiTermQueryWrapper currently rewrites to a SpanOrQuery with as many
> clauses as there are matching terms. It would be nice to be able to limit
> this in a slightly nicer way than using TopTerms, which for most queries just
> translates to a lexicographical ordering.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
