[
https://issues.apache.org/jira/browse/LUCENE-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-2769:
--------------------------------
Attachment: LUCENE-2769_norms.patch
here is a hack patch for Uwe's idea about the norms.
we need to change SegmentMerger to not call norms on the top-level IR but
populate its normBuffer from the subs.
in my opinion it seems crazy we are currently creating these big arrays this
way (yeah there is the hairy code for re-open that re-uses the big merged cache
for the NRT case, but still).
Maybe i am missing something.
> FilterIndexReader in trunk does not implement getSequentialSubReaders()
> correctly
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-2769
> URL: https://issues.apache.org/jira/browse/LUCENE-2769
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Uwe Schindler
> Attachments: LUCENE-2769.patch, LUCENE-2769.patch,
> LUCENE-2769_norms.patch
>
>
> Since LUCENE-2459, getSequentialSubReaders() in FilterIndexReader returns
> null, so it returns an atomic reader. But If you call then any of the enum
> methods, it throws Exception because the underlying reader is not atomic.
> We should move the null-returning method to SlowMultiReaderWrapper and fix
> FilterIndexReader's default to return in.getSequentialSubReaders(). Ideally
> an implementation must of course also wrap the sub-readers.
> If we change this we have to look into other Impls like the
> MultiPassIndexSplitter if we need to add atomicity.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
