[ 
https://issues.apache.org/jira/browse/LUCENE-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869442#comment-13869442
 ] 

Mikhail Khludnev commented on LUCENE-5393:
------------------------------------------

[~rcmuir] can you briefly describe testing approach? I guess it should be 
something like AssertingDocValuesProducer which can wrap any DVP and assert 
that callers doesn't modify bytes[]. Then we need to cover all DV clients by 
these asserts. Do I get you right or what you have in mind?

> remove codec byte[] cloning in BinaryDocValues api
> --------------------------------------------------
>
>                 Key: LUCENE-5393
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5393
>             Project: Lucene - Core
>          Issue Type: Task
>            Reporter: Robert Muir
>
> I can attack this (at least in trunk/5.0, we can discuss if/when it should 
> happen for 4.x).
> See the mailing list for more discussion. this was done intentionally, to 
> prevent lots of reuse bugs.
> The issue is very simple, lots of old fieldcache-type logic has it because 
> things used to be immutable Strings or because they rely on things being in a 
> large array:
> {code}
> byte[] b1 = get(doc1);
> byte[] b2 = get(doc2);
> // some code that expects b1 to be unchanged.
> {code}
> Currently each get() internally is cloning the bytes, for safety. but this is 
> really bad for code like faceting (which is going to decompress integers and 
> never needs to save bytes), and its even stupid for things like 
> fieldcomparator (where in general its doing comparisons, and only rarely 
> needs to save a copy of the bytes for later).
> I can address it with lots of tests (i added a lot in general anyway since 
> the time of adding this TODO, but more would make me feel safer).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to