Hi Bernd,
> Nevertheless I'm in the need of the functionality to change the stored
value
> during analysis or tokenization or filtering (what ever works).
>
> Thats how it can be done in FAST FDS/ESP (full processing) compared to
> Lucene/Solr (sparse processing).
>
> Do you have any idea, how
t any result!
>
> I'd suggest to read a book about Lucene/Solr first :-)
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -Original Message-
>> From: Bernd
@uni-bielefeld.de]
> Sent: Friday, November 26, 2010 8:23 AM
> To: java-user@lucene.apache.org
> Subject: Re: not indexing analyzed field
>
> Hi Uwe,
>
> my fieldType and fields are as follows:
>
>
>class="de.ubbielefeld.solr.analysis.TextMessageDigestAna
Hi Erik,
the "problem" can be described as follows:
- we have a database for users
- users can search and mark/store records for watching
- the record marker is the unique path to the source and also the unique record
id of the database
- therefore we decided to sha256 the id as backreference fro
Can you "define the problem away"? That is, why do you want to store it at
all?
If there's no value to the users in seeing the encoded value, just don't
store it.
You can still search on the encoded value if in that case
Which is a way of saying that I don't know, off the top of my head, how
y
Hi Erik,
I see my problem, caused by a misunderstanding of the indexing by lucene.
I guess its due to the fact that FAST Data Search has real processing pipelines.
Youre right I use Solr but, as a matter of fact, in this special case
I really want to change the indexed _and_ stored data.
For secu
So, you're using Solr, right? And have a custom analyzer? If that's the
case, Uwe pointed you in the right direction and I think everything may
be working fine, or at least as I'd expect.
Specifying stored="true" puts a verbatim, unanalyzed copy of the data
in the index. When you display a field i
Hi Uwe,
my fieldType and fields are as follows:
So the field dcdocid has the attribute *stored* which I can also see
in the debugger.
Why should I analyze a stored field?
I don't know if I need to analyze it, I also tried a filter but also no success.
My understanding is to send somet
Hi Erik,
my evidence is that I load a single document into an empty index
with a field "id" and a second field "dcdocid". The field "dcdocid"
has the word "foo". This goes through my analyzer and changes to
MD5 string which is then "acbd18db4cc2f85cedef654fccc4a4d8".
After indexing and commit a se
field.fieldsData is used for the stored field contents and so only *stored*
in index, of course not analyzed (why should I analyze a stored field). The
indexed tokens go of course through your analyzer and the returned tokens
are indexed as terms. Where is the problem?
-
Uwe Schindler
H.-H.-Me
What is your evidence that "the result never reaches the index?"
Are you sure:
1> you commit afterwards
2> you reopen the underlying reader to see
3> if you don't store the value for the field, how are you sure?
4> If you search and don't find it, did you index it?
First, I'd be sure the value in
11 matches
Mail list logo
