lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-3866) Make CompositeReader.getSequentialSubReaders() and the corresponding IndexReaderContext methods return unmodifiable List<R extends IndexReader>
Date Tue, 13 Mar 2012 11:51:38 GMT

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

Robert Muir commented on LUCENE-3866:
-------------------------------------

Thanks for opening!

{quote}
The binary search of reader-ids inside BaseCompositeReader can still be done with the internal
protected array,
{quote}

That's unaffected here right? Because starts[] is a separate problem. Why isnt this private?
I made it private,
only MultiPassIndexSplitter.FakeDeleteIndexReader is affected. In my opinion we should fix
this too, the fix would
be to just have a protected method in BaseComposite: int getDocStart(int readerIndex). Between
this and readerIndex(),
subclasses then have all they need.

                
> Make CompositeReader.getSequentialSubReaders() and the corresponding IndexReaderContext
methods return unmodifiable List<R extends IndexReader>
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3866
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3866
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 4.0
>
>
> Since Lucene 2.9 we have the method getSequentialSubReader() returning IndexReader[].
Based on hardly-to-debug errors in user's code, Robert and me realized that returning an array
from a public API is an anti-pattern. If the array is intended to be modifiable (like byte[]
in terms,...), it is fine to use arrays in public APIs, but not, if the array must be protected
from modification. As IndexReaders are 100% unmodifiable in trunk code (no deletions,...),
the only possibility to corrumpt the reader is by modifying the array returned by getSequentialSubReaders().
We should prevent this.
> The same theoretically applies to FieldCache, too - but the party that is afraid of performance
problems is too big to fight against that :(
> For getSequentialSubReaders there is no performance problem at all. The binary search
of reader-ids inside BaseCompositeReader can still be done with the internal protected array,
but public APIs should expose only a unmodifiable List. The same applies to leaves() and children()
in IndexReaderContext. This change to list would also allow to make CompositeReader and CompositeReaderContext
Iterable<R extends IndexReader>, so some loops would look nice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message