If we make this change (migrate to "boolean TokenStream.reset()"),
what would IndexWriter do if it calls reset and false is returned?
Are you saying that you want to get to the point where we force all
TokenStream subclasses to implement reset (and return true)? Should
we just eventually make reset() abstract (somehow in an incremental
backwards compatible way, if there is one)?
Mike
Karl Wettin wrote:
4 jul 2008 kl. 21.02 skrev Michael McCandless:
But what would cause reset() to not actually work?
Extentions of TokenStream does not have handle reset():
/** Resets this stream to the beginning. This is an
* optional operation, so subclasses may or may not
* implement this method. Reset() is not needed for
* the standard indexing process. However, if the Tokens
* of a TokenStream are intended to be consumed more than
* once, it is necessary to implement reset().
*/
public void reset() throws IOException {}
And what is a composite stream?
I just came up with that name. As in the composite pattern. A
stream formed by one or more streams and perhaps some code. A
TokenFilter would be the most simple one.
I'm just a little confused on the use case here I think...
Here are a few things I think of:
Perhaps my composite stream that I iterated for pre processing
reasons is really simple to reset but the input streams does not
support reset.
If you add a stream to a field and that stream is exhausted at
addDocument beacuse it did not support reset, you'll end up with an
empty field without a warning.
It is a waste of esources to reset all the parts of a composite
stream if one of the parts failed to reset.
karl
Mike
Karl Wettin wrote:
I just want to know if my token stream managed to reset or not.
Especially that parts of composite streams.
karl
4 jul 2008 kl. 12.13 skrev Michael McCandless:
Karl,
I'm sort of confused by this proposal. What is the driver here?
It seems like the overall goal is to have reset() return a
boolean stating whether it was actually implemented by the
subclass of TokenStream?
Mike
Karl Wettin wrote:
How about depricating
> public void reset() throws IOException {}
and refactor it to allow making sure the stream was reset?
To avoid break backwards compatibillity with extentions of the
TokenStream currently in trunk one could introduce something
like this:
> /**
> * @param requireConfirmedReset
> * @throws ResetException An IOException thrown if parameter
requireReset
> * was set true and the stream could not be reset.
> */
> public void reset(boolean requireConfirmedReset)
> throws IOException, ResetException {
> reset();
> if(requireConfirmedReset) throw new ResetException();
> }
and then depricate this new method at some strategic time to
introduce an exception-less solution like:
> /** @return true if this stream was successfully reset. */
> public boolean reset() throws IOException { return false; }
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
