Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of jak-lucene-user@m.gmane.org
 designates 80.91.229.12 as permitted sender)
To: java-user@lucene.apache.org
From: Constantine Vetoshev <gepardcv@gmail.com>
Subject: Re: Fields with Field.Store.NO and Field.Index.ANALYZED not being
 indexed
Date: Sun, 29 Aug 2010 23:33:52 -0400
Lines: 19
Message-ID: 
 <m2mxs4zsdb.fsf@athena.local.i-did-not-set--mail-host-address--so-tickle-me>
References: 
 <m2bpecmbff.fsf@athena.local.i-did-not-set--mail-host-address--so-tickle-me>
	<359a92831003251327j110470d7r5380db0910910747@mail.gmail.com>
	<m2tymdyx1o.fsf_-_@athena.local.i-did-not-set--mail-host-address--so-tickle-me>
	<001d01cb47bb$8231cf70$86956e50$@thetaphi.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (darwin)
Cancel-Lock: sha1:0pbCSNfm6wZQddYO34ljt2RhxAU=

"Uwe Schindler" <uwe@thetaphi.de> writes:
> You cannot retrieve non-stored fields. They are analyzed and tokenized
> during indexing and this is a one-way transformation. If you update
> documents you have to reindex the contents. If you do not have access to the
> original contents anymore, you may consider adding a stored-only "raw
> document" field, that contains everything to rebuild the indexed fields. In
> our installation, we have a stored field containing the JSON/XML source
> document to do this.

Thanks, that helps.

Since it seems that I have to keep the raw data around, is there any
reason not to just make that data's field both stored and analyzed? I'm
just wondering why you use a separate stored-only field: a Lucene
limitation or some app-specific reason?

--
Regards,
Constantine Vetoshev


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