[
https://issues.apache.org/jira/browse/LUCENE-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205322#comment-13205322
]
Uwe Schindler edited comment on LUCENE-3736 at 2/10/12 10:11 AM:
-----------------------------------------------------------------
Patch that fixes the bugs in Mike's code and also allows decoupled stored
fields readers:
- moved the composite reader checks from the main builder loop (where it was
wrongly placed) to a validate method acting only on the top-level readers
- I improved the tests to have a different number of documents, subreaders and
parallel readers
- Current limitation is only that at least one "searchable" reader must be
there, but there can be 0..infinite stored readers
- toString() shows the unique set of parallel readers, unfortunately unsorted
(as hashed set)
- I added one more ctor PR(closeSubReaders, IR subs...), this makes code not
separating stored fields readers look better, as closeSubReaders is not an
expert option.
Mike, can I take the issue again and commit this? Thanks for the refactoring,
but as we now allow separate stored fields and main readers, the missing
builder is fine to me - grrrr
was (Author: thetaphi):
Patch that fixes the bugs in Mike's code and also allows decoupled stored
fields readers:
- moved the composite reader checks from the main builder loop (where it was
wrongly placed) to a validate method acting only on the top-level readers
- I improved the tests to have a different number of documents, subreaders and
parallel readers
- Current limitation is only that at least one "searchable" reader must be
there, but there can be 0..infinite stored readers
- toString() shows the unique set of parallel readers, unfortunately unsorted
(as hashed set)
- I added one more ctor PR(closeSubReaders, IR subs...), this makes code not
separating stored fields readers look better, as closeSubReaders is not an
expert option.
Mike, can I take the issue again and commit this? Thanks for the refactoring,
but as we now allow separate stored fields and main readers, the
> ParallelReader is now atomic, rename to ParallelAtomicReader and also add a
> ParallelCompositeReader (that requires LogDocMergePolicy to have identical
> subreader structure)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-3736
> URL: https://issues.apache.org/jira/browse/LUCENE-3736
> Project: Lucene - Java
> Issue Type: Sub-task
> Components: core/index
> Reporter: Uwe Schindler
> Assignee: Michael McCandless
> Fix For: 4.0
>
> Attachments: LUCENE-3736.patch, LUCENE-3736.patch, LUCENE-3736.patch,
> LUCENE-3736.patch, LUCENE-3736.patch, LUCENE-3736.patch, LUCENE-3736.patch,
> LUCENE-3736.patch, LUCENE-3736.patch, LUCENE-3736.patch
>
>
> The plan is:
> - Move all subreaders to ctor (builder-like API. First build reader-set, then
> call build)
> - Rename ParallelReader to ParallelAtomicReader
> - Add a ParallelCompositeReader with same builder API, but taking any
> CompositeReader-set and checks them that they are aligned (docStarts
> identical). The subreaders are ParallelAtomicReaders.
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
