> >> I would recommend to *not* use QueryWrapperFilter and instead wrap with
> ConstantScoreQuery and add it to the query as a Boolean MUST clause. In that
> case it should work fine. There is no performance increase by using
> QueryWrapperFilter, so no reason to use it.
> >
e no available at the
>> moment).
>>
>> My plan to fix this is to make Filters behave like queries (with a rewrite()
>> method), so the correct context can be passed to a "rewritten" filter (when
>> QueryWrapperFilter rewrites, it rewrites also the query). The
behave like queries (with a rewrite()
> method), so the correct context can be passed to a "rewritten" filter (when
> QueryWrapperFilter rewrites, it rewrites also the query). The current
> approach is for performance reasons, because without rewrite, you would have
>
behave like queries (with a rewrite()
> method), so the correct context can be passed to a "rewritten" filter (when
> QueryWrapperFilter rewrites, it rewrites also the query). The current
> approach is for performance reasons, because without rewrite, you would have
>
to a "rewritten" filter (when
QueryWrapperFilter rewrites, it rewrites also the query). The current approach
is for performance reasons, because without rewrite, you would have no
persistent "state" information between index segments, so the Query has to be
rewritten on the
Hello,
I have some custom queries & scorer that need to able to construct the
"global" docIds (doc + docBase).
But when i use these in a QueryWrapperFilter they no longer work,
because QueryWrapperFilter.getDocIdSet uses a "private context"
(context.reader().getContex
I've created https://issues.apache.org/jira/browse/LUCENE-3442 to document this.
Thanks for your help,
Dan
- Original Message -
From: Uwe Schindler
To: java-user@lucene.apache.org
Cc:
Sent: Tuesday, September 20, 2011 11:01 AM
Subject: RE: QueryWrapperFilter and DocIdSetIterat
ahoo.com
> Subject: RE: QueryWrapperFilter and DocIdSetIterator
>
> Hi,
>
> I don't see a problem in your code:
> If you look at the source code of QueryWrapperFilter, it will never return
> NULL, so it returns always a DocIdSet theat itself returns the Scorer of
the
Hi,
I don't see a problem in your code:
If you look at the source code of QueryWrapperFilter, it will never return
NULL, so it returns always a DocIdSet theat itself returns the Scorer of the
query as Iterator.
@Override
public DocIdSet getDocIdSet(final IndexReader reader) t
I've been trying to use the QueryWrapperFilter as part of composing a set of
filters. Are there limitations on the types of queries it can wrap? When I try
to get the DocSetIdIterator for the filter it comes up null. This happens even
when the query is a simple TermQuery.
The following
Hi David,
On 4/22/2009 at 4:15 PM, David Seltzer wrote:
> I have some code that dynamically creates a Boolean query designed to
> work as a filter. After the query runs I end up with this filter.
>
> Filter: QueryWrapperFilter(+(-SourceID:100)
> +spanNear([Article
Hi Everyone,
I have some code that dynamically creates a Boolean query designed to
work as a filter. After the query runs I end up with this filter.
Filter: QueryWrapperFilter(+(-SourceID:100)
+spanNear([ArticleContent:nuclear, ArticleContent:proliferation], 30,
false))
My expectation is that
"B", entity B has
> a m:1 bidirectional relationship with entity "C", the foreign Key in "B" is
> "c_id". My filter condition would be like "filter the fulltext search for
> entries where the c_id equals some value", where value is given.
>
ilter condition would be like "filter the fulltext search for
entries where the c_id equals some value", where value is given.
I thought of using the QueryWrapperFilter. But the JavaDoc says for the
TermQuery: "A Query that matches documents containing a term.". My problem
is th
What version of Lucene are you using? Can you share the snippet of
code that does this? Are you keeping the QueryWrapperFilter around
from search to search?
On Jun 27, 2008, at 5:24 PM, Jordon Saardchit wrote:
Hello All,
Sort of new to lucene but have a general question in regards to
12000 hits in around
7000ms
* RangeQuery: (term TO term) Which returns roughly 6000 hits in around
200ms
Now for performance reasons, I am attempting to run the WildcardQuery
against only the RangeQuery hits (6000 as opposed to 7 million), via
using a QueryWrapperFilter (constructed with my
Op Thursday 17 April 2008 06:37:18 schreef Michael Stoppelman:
> Actually, I screwed up the timing info. I wasn't including the time
> for the QueryWrapperFilter#bits(IndexReader) call. Sadly,
> it actually takes longer than the original query that had both terms
> included. Bum
Actually, I screwed up the timing info. I wasn't including the time for the
QueryWrapperFilter#bits(IndexReader) call. Sadly,
it actually takes longer than the original query that had both terms
included. Bummer. I had really convinced myself till the
thought came to me at lunch :).
-M
O
Michael Stoppelman skrev:
Hi all,
I've been doing some performance testing and found that using
QueryWrapperFilter for a location field
restriction I have to do allows my search results to approach 5-10ms. This
was surprising.
Before the performance was between 50ms-100ms.
The queries
Hi all,
I've been doing some performance testing and found that using
QueryWrapperFilter for a location field
restriction I have to do allows my search results to approach 5-10ms. This
was surprising.
Before the performance was between 50ms-100ms.
The queries from before the optimization
20 matches
Mail list logo
