[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=14953138#comment-14953138
]
Tommaso Teofili edited comment on LUCENE-6821 at 10/12/15 1:52 PM:
---
do you mean the {{BytesRef.deepCopyOf}} at
https://github.com/apache/lucene-solr/blob/trunk/lucene/classification/src/java/org/apache/lucene/classification/SimpleNaiveBayesClassifier.java#L154
?
If yes, that's because the reference is updated and used in the
{{ClassificationResult}}. I'll see if I can simplify that.
was (Author: teofili):
do you mean the {{BytesRef.deepCopyOf}} at
https://github.com/apache/lucene-solr/blob/trunk/lucene/classification/src/java/org/apache/lucene/classification/SimpleNaiveBayesClassifier.java#L154
?
yes, that's because the reference is updated and used in the
{{ClassificationResult}}. I'll see if I can simplify that.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[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=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.elsc...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
