"if you do not have access to the original contents" is the key if Uwe's
comment. You do not need a separate field at all, it all depends upon
your situation. There's no problem in indexing AND storing f field.
HTH
Erick
On Sun, Aug 29, 2010 at 11:33 PM, Constantine Vetoshev
wrote:
> "Uwe Schind
"Uwe Schindler" 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
we Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Constantine Vetoshev [mailto:gepar...@gmail.com]
> > Sent: Sunday, August 29, 2010 10:38 PM
> > To: java-user@l
e-
> From: Constantine Vetoshev [mailto:gepar...@gmail.com]
> Sent: Sunday, August 29, 2010 10:38 PM
> To: java-user@lucene.apache.org
> Subject: Re: Fields with Field.Store.NO and Field.Index.ANALYZED not being
> indexed
>
> Thanks Erick.
>
> I finally had tim
Thanks Erick.
I finally had time to go back and look at this problem. I discovered
that the analyzed fields work fine for searching until I use
IndexWriter.updateDocument().
The way my application runs, it has to update documents several times to
update one specific field. The update code queries
I would be extraordinarily surprised if this was in Lucene, this is so
basic to how it works that the howls would be heard world-round .
So I'm guessing it's in your code. Could you show it to us? Or, better
yet, create a small, self-contained test case that illustrates your problem?
Also, what a
