You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "David Smiley (JIRA)" <ji...@apache.org> on 2018/07/05 22:31:00 UTC
[jira] [Assigned] (LUCENE-6513) Allow limits on
SpanMultiTermQueryWrapper expansion
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org