Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of farhang@gmail.com designates
 74.125.78.26 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=os6PSYocfE+TjbTdq3JH0eGCcnrlMeXWu1lldnI+7S7Wz1RNuxLHmiQMeuoN1Mii7Y
         jK3PQ5mTdrmPX0+PXCId9kag1RnwWdRFAocBmeAsFHxtgZ+KRTszWfj5Ue3pmZfJw1Sg
         tHb06EfPhA1k0OeJdxhCuYZpdd1kB7NoxnBL8=
MIME-Version: 1.0
In-Reply-To: <4B442D77.9030006@gmail.com>
References: <b0f7deba1001050901u405d25ffm32187b0eb49c1739@mail.gmail.com>
	 <9ac0c6aa1001051200v224a8ad3p5dcb1bc00807bcd9@mail.gmail.com>
	 <4B442D77.9030006@gmail.com>
Date: Tue, 5 Jan 2010 23:50:34 -0700
Message-ID: <b0f7deba1001052250v1b5ff08at3d4c82c1cd5596ec@mail.gmail.com>
Subject: Re: Switching from Store.YES to Store.NO
From: Babak Farhang <farhang@gmail.com>
To: java-user@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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, Chris Lu <chris.lu@gmail.com> wrote:
> 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.dbsight.com/index.php?title=Create_Lucene_Database_Search_in_3_minutes
> DBSight customer, a shopping comparison site, (anonymous per request) got
> 2.6 Million Euro funding!
>
>
> 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't think this (what happens when certain schema changes happen
>> mid-indexing) is well documented, in general.
>>
>> Mike
>>
>> On Tue, Jan 5, 2010 at 12:01 PM, Babak Farhang <farhang@gmail.com> wrote:
>>
>>>
>>> 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 as if they were never stored.) Which brings up my
>>> question.  What effect, if any, does switching to Store.NO have when
>>> existing documents in the index already use Store.YES for that field?
>>> Will the change take effect for the new docs added to the index?  Are
>>> there any side-effects to consider?
>>>
>>> Also, more generally, since the Lucene API does not guard against
>>> changing the document "schema" as the index is being built, I imagine
>>> the effects of such mid-stream "schema" changes might be documented
>>> somewhere.  Please share, if you know of such a document.
>>>
>>> Regards,
>>> -Babak
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
>>
>

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