Just thinking out loud... haven't looked at your patch yet (one of
these days I will be back up for air)
My initial thought is that you would have a factory that produced both
the Reader and the Writer as a pair, or was at least aware of what to
go get from the Writer
Something like:
class IndexFactory{
IndexWriter getWriter()
IndexReader getReader()
//Not sure if this is needed yet, but????
IndexReader getReader(IndexWriter)
}
The factory (or whatever you want to call it) is responsible for
making sure the Writer and Reader have the pieces they need, i.e. the
SegmentInfos.
The first getReader will get you the plain old Reader that everyone
knows and loves today (assuming there is a benefit to keeping it
around), the second one knows what to get off the Writer to create the
appropriate Reader.
It's nothing particularly hard to implement over what you are
proposing, I don't think. Just trying to keep the Reader out of the
Writer from an API cleanliness standpoint.
-Grant
On Jan 12, 2009, at 12:55 PM, Jason Rutherglen wrote:
Grant,
Do you have a proposal in mind? It would help to suggest something
like some classes and methods to help understand an alternative to
what is being discussed.
-J
On Fri, Jan 9, 2009 at 12:05 PM, Grant Ingersoll
<gsing...@apache.org> wrote:
I realize we aren't adding read functionality to the Writer, but it
would be coupling the Writer to the Reader nonetheless. I
understand it is brainstorming (like I said, not trying to distract
from the discussion), just saying that if the Reader and the Writer
both need access to the underlying data structures, then we should
refactor to make that possible, not just glom the Reader onto the
Writer. I suspect if that is done, anyway, that it may make the
bigger picture a bit clearer, too.
On Jan 9, 2009, at 2:53 PM, Michael McCandless wrote:
Grant Ingersoll wrote:
We've spent a lot of time up until now getting write functionality
out of the Reader, and now we are going to add read functionality
into the Writer?
Well... we're not really adding read functionality into IW; instead,
we are asking IW to open the reader for us, except the reader is
provided the SegmentInfos it should use from IW (instead of trying to
find the latest segments_N file in the Directory).
Ie, what IW.getReader returns is an otherwise normal
MultiSegmentReader.
The goal is to allow an IndexReader to access segments flushed but
not yet committed by IW. These segments are normally "private" to IW,
in memory in its SegmentInfos instance.
And this is all just thinking-out-loud-brainstorming. There are
still many
details to work through...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
--------------------------
Grant Ingersoll
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
