Hi
I have a situation whereby the following filter query works with Lucene
3.8.1
ChainedFilter: [QueryWrapperFilter(+receivedate:[20140701 TO
20140731] +cat:email)
org.apache.lucene.sandbox.queries.DuplicateFilter@6a894d44 ]
With Lucene 4.0.0, the query always returns zero results.
Hi
This query does not work either:
QueryWrapperFilter(+archivedate:[20140708 TO 20140731] +cat:email)
Thus, in our mind, Lucene 4.0.0 range query is broken. We tried to
downgrade to v3.8.1, but it wont read indexes created by 4.0.0.
Any recommendations on how to get out of this bin
Hi Uwe,
Where can find the detail introduction about the algorithm of mmap in
java and OS? I did not find anything useful from jdk source code.
For example: byte b=curBuf.get(); System.out.printf(b);
When running get method, the jvm will not invoke the FS to read file in disk.
When r
All
As a further to the below.
We are able to search by range query when the indexes are created by
3.8.1. When the date field is indexed by 4.0.0, search with date range
query doesn't work.
Here's how we index the date field.
String date = DateUtil.convertDatetoString((Date)
value,DateUt
This has nothing to do with mmap.
This is an optimization done by the compiler. If you don't use the return value
of a method and the method itself has no side effects, it is never called.
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
If you index as a long field, you have to use NumericRangeQuery to query. A
simple TermRangeQuery as created by QueryParser does not work, because it
cannot handle numeric fields.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Ori
Uwe
Thanks for the suggestion.
When I inspect the query in Eclipse, I can clearly see that a
NumericRangeQuery is constructed.
Why would this query work in an older version of Lucene but not 4.0.0.?
Jamie
On 2014/07/16, 11:45 AM, Uwe Schindler wrote:
If you index as a long field, you have
Here it is
return NumericRangeQuery.newLongRange(field.getIndexField(), 8,
Long.parseLong(query.getLowerTerm().utf8ToString()),
Long.parseLong(query.getUpperTerm().utf8ToString()),
query.includesLower(), query.includesUpper());
Range query appears broken in Lucene 4.0.0.
On
Uwe
is there anyway we can downgrade to 3.8.1 while being able to read
indexes created from 4.0.0?
On 2014/07/16, 11:45 AM, Uwe Schindler wrote:
If you index as a long field, you have to use NumericRangeQuery to query. A
simple TermRangeQuery as created by QueryParser does not work, because
Sorry, no you cannot downgrade!
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Jamie [mailto:ja...@mailarchiva.com]
> Sent: Wednesday, July 16, 2014 12:14 PM
> To: java-user@lucene.apache.org
> Subject:
Uwe
The range query works with lindexes created by 3.8.1, but not 4.0.0. To
me, this indicates that Lucene 4.0.0 is not indexing these longs
correctly, or something of the sort. Do you have any ideas on where to
look?
Jamie
On 2014/07/16, 12:15 PM, Uwe Schindler wrote:
Sorry, no you canno
Why do you use QueryWrapperFilter instead of using NumericRangeFilter directly?
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Jamie [mailto:ja...@mailarchiva.com]
> Sent: Wednesday, July 16, 2014 11:15
Hi,
It is definitely not broken in 4.x. There may be other problems in your code
like non-consistent precisionSteps or other.
If you could give a complete self-contained test case, I may help you to find
your bug.
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi
Sorry I cannot give you any hints, except that handling of Filters and Queries
and per-segment search changed dramatically in Lucene 4 (see migration guide).
Maybe you have another general issue in your code.
I need aa self-contained test case to understand what you are doing wrong.
-
Uwe S
Uwe
Thank you.
I think your earlier hint regarding precision steps solved it. I
noticed that new Long was created with a precision step of 4, but my
range query was creating precision step of 8.
return NumericRangeQuery.newLongRange(field.getIndexField(), 8,
Long.parseLong(query.getLowerTe
Sorry to suggest that it was a Lucene bug. It is rare we encounter
Lucene bugs - a testament to your code quality. Much appreciate!
On 2014/07/16, 12:33 PM, Jamie wrote:
Uwe
Thank you.
I think your earlier hint regarding precision steps solved it. I
noticed that new Long was created with a
Hi everyone,
I created an index with three documents, ran a query, and noted the scores.
Then I deleted one of the documents using IndexWriter.tryDeleteDocument, and
then re-added the exact same document. (I saved the Document in an instance
variable, so I couldn't have accidentally changed any of
: I created an index with three documents, ran a query, and noted the scores.
: Then I deleted one of the documents using IndexWriter.tryDeleteDocument, and
: then re-added the exact same document. (I saved the Document in an instance
: variable, so I couldn't have accidentally changed any of the
Chris Hostetter-3 wrote
> Deleted docments still affect term stats like IDF until the are expunged.
> -Hoss
>
> -
> To unsubscribe, e-mail:
> java-user-unsubscribe@.apache
> For additional commands, e-mail:
> java-user-help
Yes, it 's obviously optimized by jit compiler of hotspot.
-- Original --
From: "Uwe Schindler";;
Date: Wed, Jul 16, 2014 05:44 PM
To: "java-user";
"'wangzhijiang999'";
Subject: RE: 答复：答复：答复：mmap confusion in lucene
This has nothing to do with mmap.
20 matches
Mail list logo
