You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Paul Elschot (JIRA)" <ji...@apache.org> on 2015/10/03 22:54:26 UTC
[jira] [Comment Edited] (LUCENE-6821) TermQuery's constructors
should clone the incoming term
[ https://issues.apache.org/jira/browse/LUCENE-6821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14942449#comment-14942449 ]
Paul Elschot edited comment on LUCENE-6821 at 10/3/15 8:53 PM:
---------------------------------------------------------------
2nd patch of 3 October 2015.
In addition to the previous patch, this also
- deletes the Term cloning in PhraseQuery,
- adds a Term constructor from a BytesRefBuilder, and
- removes BytesRef copying at Term construction from Solr's FieldType, SolrIndexSearcher, FacetField and SimpleMLTQParser.
was (Author: paul.elschot@xs4all.nl):
2nd patch of 3 October 2015.
In addition to the previous patch, this also
- deletes the Term cloning in PhraseQuery, and
- removes deepCopyOf calls at Term construction from Solr's FieldType, SolrIndexSearcher, FacetField and SimpleMLTQParser.
> TermQuery's constructors should clone the incoming term
> -------------------------------------------------------
>
> Key: LUCENE-6821
> URL: https://issues.apache.org/jira/browse/LUCENE-6821
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-6821.patch, LUCENE-6821.patch
>
>
> This is a follow-up of LUCENE-6435: the bug stems from the fact that you can build term queries out of shared BytesRef objects (such as the ones returned by TermsEnum.next), which is a bit trappy. If TermQuery's constructors would clone the incoming term, we wouldn't have this trap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org