This is a good question...
Merging will not alter the previously stored fields -- it will just
carry them forward to the next segment.
So any docs that have stored fields will retain them through merging.
(And, yes, merging is done "under the hood", separately from "indexing").
This is in contr
I'm curious (:-)) about what do you mean by *adjusted*? Also, not sure
I have the nomenclature here right, but isn't indexing functionally
separate from merging segments? (You *index* to a segment which may,
or may not, be later *merged* with other segments, no?)
On Tue, Jan 5, 2010 at 11:28 PM, C
Just curious, will it be adjusted during indexing when merging segments?
Thanks!
--
Chris Lu
-
Instant Scalable Full-Text Search On Any Database/Application
site: http://www.dbsight.net
demo: http://search.dbsight.com
Lucene Database Search in 3 minutes:
http://wiki.dbsi
Thanks!
On Tue, Jan 5, 2010 at 1:00 PM, Michael McCandless
wrote:
> Making that switch is fine.
>
> The change will not be retroactive, ie, all previously indexed docs
> with Store.YES will continue to store their fields. But new docs
> won't store their fields if you specify Store.NO.
>
> I don
Making that switch is fine.
The change will not be retroactive, ie, all previously indexed docs
with Store.YES will continue to store their fields. But new docs
won't store their fields if you specify Store.NO.
I don't think this (what happens when certain schema changes happen
mid-indexing) is
Hi,
A review of the requirements of the project I'm working on has led us
to conclude that going forward we don't need Lucene to store certain
field values--just index. Owing to the large size of the data, we
can't really afford to reindex everything, (Going forward, we plan to
treat these fields
