[
https://issues.apache.org/jira/browse/LUCENE-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177806#comment-15177806
]
ASF GitHub Bot commented on LUCENE-7064:
----------------------------------------
GitHub user LucVL opened a pull request:
https://github.com/apache/lucene-solr/pull/19
LUCENE-7064: Make MultiPhraseQuery immutable
This PR is based at the highest commit point common to master, branch_6x
and branch_6_0 so it should be easy to merge with any or all of them.
My original mail to the dev list doesn't seem to get through, so I repeat
it here:
> While checking how to migrate my custom components from lucene/solr 5.1
to 6.x I stumbled upon the fact that oal.search.MultiPhraseQuery is not
immutable like most other implementations (see e.g.:
https://issues.apache.org/jira/browse/LUCENE-6531)
>
> Since it is part of the public API I would suggest splitting it in an
immutable class and a builder like was done for most other Queries *before*
releasing an official 6.x version.
>
> I did a quick scan through all derived classes of Query and I compiled
the following list (ignoring sources in test or contrib folders)
> Some of them are already marked as experimental (but should perhaps
receive the "official" @lucene.experimental tag ?)
> For some it's possibly not an issue since they should never end up in a
filter cache (like MoreLikeThisQuery ?), but then a comment specifying the
exception to the rule should perhaps be added.
>
> I'll probably already have a go at the MultiPhraseQuery case shortly and
create a JIRA issue with a PR for it.
>
> Luc Vanlerberghe
>
> lucene/search:
> - org.apache.lucene.search.MultiPhraseQuery
>
> lucene/queries:
> - org.apache.lucene.queries.CommonTermsQuery
> - org.apache.lucene.queries.CustomScoreQuery (marked as
@lucene.experimental)
> - org.apache.lucene.queries.mlt.MoreLikeThisQuery
>
> lucene/suggest:
> - org.apache.lucene.search.suggest.document.ContextQuery (marked as
@lucene.experimental)
>
> lucene/facet:
> - org.apache.lucene.facet.DrillDownQuery (marked as @lucene.experimental)
>
> solr/core:
> - org.apache.solr.search.ExtendedQueryBase
> Several derived classes, among which:
> - org.apache.solr.query.FilterQuery
> - org.apache.solr.query.SolrRangeQuery (marked as @lucene.experimental)
> - org.apache.solr.search.RankQuery (marked in comment as experimental,
but not its derived classes)
> - org.apache.solr.search.WrappedQuery
> - org.apache.solr.search.join.GraphQuery (marked as @lucene.experimental)
> - org.apache.solr.search.SolrConstantScoreQuery (marked in comment as
experimental, but not the derived FunctionRangeQuery)
>
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/LucVL/lucene-solr lucene-7064
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/lucene-solr/pull/19.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #19
----
commit 223eaa2bcf74ea3b363abfb161b3771b09f48281
Author: Luc Vanlerberghe <[email protected]>
Date: 2016-03-03T10:52:14Z
LUCENE-7064: Split MultiPhraseQuery into an immutable class and a Builder
commit 1b4c0ed77fe8b22c7a04b2879b34514b0ac05d0d
Author: Luc Vanlerberghe <[email protected]>
Date: 2016-03-03T13:02:51Z
LUCENE-7064: Updated tests
----
> Make MultiPhraseQuery immutable
> -------------------------------
>
> Key: LUCENE-7064
> URL: https://issues.apache.org/jira/browse/LUCENE-7064
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Reporter: Luc Vanlerberghe
> Priority: Minor
> Fix For: master, 6.0
>
>
> See LUCENE-6531
> Mutable queries are an issue for automatic filter caching since modifying a
> query after it has been put into the cache will corrupt the cache. We should
> make all queries immutable (up to the boost) to avoid this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
