[
https://issues.apache.org/jira/browse/LUCENE-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345005#comment-14345005
]
Robert Muir commented on LUCENE-6321:
-------------------------------------
Looks ok in general.
Not sure about Term.clone() changes, i think maybe this should be an explicit
deepCopyOf method just like bytesref?
In general, who is modifying term bytes? This seems like an abuse case, and its
gonna be problematic everywhere in lucene apis if you do this.
But maybe its a good idea to do a little "extra" clone work to make these core
queries defensive. Another thing we could do instead would be a best effort
check where we actually throw concurrentmodificationexception or something,
that might be more interesting.
> Make oal.index.Term more defensive
> ----------------------------------
>
> Key: LUCENE-6321
> URL: https://issues.apache.org/jira/browse/LUCENE-6321
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-6321.patch
>
>
> oal.index.Term has a Term(String field, BytesRef termBytes) constructor. Even
> though it warns that the term bytes should not be reused, I'm wondering that
> we should make it more defensive.
> {noformat}
> * <p>WARNING: the provided BytesRef is not copied, but used directly.
> * Therefore the bytes should not be modified after construction, for
> * example, you should clone a copy by {@link BytesRef#deepCopyOf}
> * rather than pass reused bytes from a TermsEnum.
> {noformat}
> For example if you have term queries in your query cache and they are
> modified in-place, it would have very bad consequences and would be hard to
> diagnose.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
