Alternatively use doc.getFields().clear() on each iteration.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Ian Lea [mailto:ian@gmail.com]
> Sent: Tuesday, December 29, 2009 10:18 PM
> To: java-user@
Hi
You need to move the Document doc = new Document(); line to inside
your for loop. The code as it stands is adding data to a single
document instance that is being added to the index for each note, with
ever increasing amounts of data.
Or look at reusing Field instances with setValue() calls.
: References: <4b385338.9000...@gmail.com>
: <00e801ca8790$4ca2ab90$1b4f0...@ufsoft.com.cn>
: Subject: CANNOT use a * or ? symbol as the first character of a search.
http://people.apache.org/~hossman/#threadhijack
Thread Hijacking on Mailing Lists
When starting a new discussion on a mailing
Hi,
I am creating an index successfully and the field called "note" that I am
searching against has the term "background". But when I run the query it
returns some completely unrelated term for the first hit. Here is the code:
List employeeNotes =
employeeDAO.getAllEmployeeNotes(clientId
OK 10x for the advises Uwe :)
Cheers,
Ivan
Uwe Schindler wrote:
I forgot:
For old 2.4 indexes this would also work, as the compressed fields appear as
uncompressed. So the detection with binary/string also works here.
Please note, as soon as you optimize or update old indexes, compressed
fiel
I forgot:
For old 2.4 indexes this would also work, as the compressed fields appear as
uncompressed. So the detection with binary/string also works here.
Please note, as soon as you optimize or update old indexes, compressed
fields get automatically decompressed. But there is nothing to do from y
10x Uwe,
That is fine :)
Cheers,
Ivan
Uwe Schindler wrote:
It is still open to you how you handle it. On my projects I normally only
store string fields. If I compress them, they are binary. So I use a similar
approach like you to compress only large fields and store the others as
string field
It is still open to you how you handle it. On my projects I normally only
store string fields. If I compress them, they are binary. So I use a similar
approach like you to compress only large fields and store the others as
string fields like before.
When I retrieve the contents of the documents I
10x Uwe for your answer,
It is good news that data compressed with Field.Store.COMPRESS with 2.4
will be retrieved properly from 3.0.
From your answer I understand that in 3.0 there is no API way to
compress some of the values of some field and not to compress other
values for the same field
You got me, thanks a lot.
This is exactly I was trying to ask (meaning find this values within the row
number 2).
I'm afraid I'm not be able to proceed because I have no access to analyzer
configuration (the system - JIRA 4.0) uses the hardcoded pre-configured set
of default analyzers.
Thanks a l
10 matches
Mail list logo
