lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: desired constructor Field("contents", new FileReader(f), Field.Store.COMPRESS)
Date Tue, 15 Aug 2006 22:08:34 GMT

: Storage is a separate mechanism from indexing, so my _guess_ is that
: if you want Readers to be stored, it would result in having to use
: the Reader twice (once for indexing and once for storage), which
: isn't possible, I don't believe, since not all Readers support the
: mark() and reset() functionality.  Besides, you will get better
: performance reading once...

To elaborate: this really isn't a flaw in the way Fields work -- the
fact that seperate mechanisms are involved doesn't result in any penalty
that you wouldn't also be facing if it was done at once....

The advantage of indexing a "Reader" based Field is that you can
tokenize/index a stream of text from a Reader without needing the entire
contents the Reader refrences in memory at one time -- it's a true stream
opeeration.  Storing a field requires the full data set to be available in
memory at once -- so if you are going to Store the data, you have to read
it into a String anyway.

That said, it would certainly be possible to have a convince method that
let you construct a Stored Field with a Reader, and it could slurp in the
whole reader for you, but it would be missleading to people who expect the
Reader based Fields to be stream based.




-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message