[
https://issues.apache.org/jira/browse/LUCENE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208351#comment-13208351
]
Uwe Schindler edited comment on LUCENE-3788 at 2/15/12 11:21 AM:
-----------------------------------------------------------------
Hi Andrzej,
maybe you misunderstood the whole thing. IndexReader itself no longer has a
Directory. If you want a synthetic Directory behind an index, subclass
DirectoryReader, which is abstract - thats easy.
I expected your issue (I know from Robert the reasons for that), so here is the
solution: Subclass DirectoryReader and override the very few methods regarding
Directory and commit/reopen; in the ctor you pass the getSequentialSubReaders()
of your ParallelCompositeReader to DirectoryReader's protected ctor -
everything else just works by magic.
We dont want Directory back in IndexReader as this is separate from the concept
of IndexReaders. The problem is mainly Solr, which heavily relies on Directory,
but Solr should be abstracted so the Directory-handling stuff is not closely
tied into the core.
Instead of opening this issue, you should create an issue at Solr to make it
not rely on an Directory (which is the wrong way for ParallelReaders on several
Directories, as it has not only one directory).
I would like to close this as won't fix.
was (Author: thetaphi):
Hi Andrzej,
maybe you misunderstood the whole thing. IndexReader itself no longer has a
Directory. If you want a synthetic Directory behind an index, subclass
DirectoryReader, which is abstract - thats easy.
I expected your issue (I know from Robert the reasons for that), so here is the
solution: Subclass DirectoryReader and override the very few methods regarding
Directory and commit; in the ctor you pass the getSequentialSubReaders() of
your ParallelCompositeReader to DirectoryReader's protected ctor - everything
else just works by magic. It would be good if you would communicate with Robert
about that Lucid-internal problem, but it's easy to solve, I can also help.
We dont want Directory back in IndexReader as this is separate from the concept
of IndexReaders. The problem is mainly Solr, which heavily relies on Directory,
but Solr should be abstracted so the Directory-handling stuff is not closely
tied into the core.
Instead of opening this issue, you should create an issue at Solr to make it
not rely on an Directory (which is the wrong was for ParallelReaders on several
Directories, as it has not only one directory).
I would like to close this as won't fix.
> Separate getting Directory from IndexReader from its concrete subclasses
> ------------------------------------------------------------------------
>
> Key: LUCENE-3788
> URL: https://issues.apache.org/jira/browse/LUCENE-3788
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/index
> Reporter: Andrzej Bialecki
> Attachments: LUCENE-3788.patch
>
>
> Currently only subclasses of DirectoryReader expose the underlying Directory
> via public final directory(). IMHO this aspect should be separated from
> DirectoryReader so that other IndexReader implementations could expose any
> underlying Directory if they wanted to. Specifically, I have a use case where
> I'd like to expose a synthetic Directory view of resources used for
> ParallelCompositeReader.
--
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: [email protected]
For additional commands, e-mail: [email protected]
