"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
I have a strange problem with Field.Store.NO and Field.Index.ANALYZED
fields with Lucene 3.0.1.
I'm testing my app with twenty test documents. Each has about ten
fields. All fields except one, "Content", are set as
Field.Store.YES. The "Content" field is set as Field.Store.NO and
Field.Index.ANALY
