lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Solr query question
Date Wed, 28 Apr 2010 23:32:06 GMT
I tried the getFilters() approach.  It turned out I also needed to create a list and do setFilters()
if getFilters() returns null, but that was easily remedied.  When this is done, it once again
works fine if the component is added "last".  But if it is added "first", we now get a stack
trace from someplace not in my search component:


	at java.util.concurrent.ConcurrentHashMap.get(
	at org.apache.solr.common.util.ConcurrentLRUCache.get(
	at org.apache.solr.handler.component.QueryComponent.process(
	at org.apache.solr.handler.component.SearchHandler.handleRequestBody(
	at org.apache.solr.handler.RequestHandlerBase.handleRequest(
	at org.apache.solr.core.SolrCore.execute(
	at org.apache.solr.servlet.SolrDispatchFilter.execute(
	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(
	at org.mortbay.jetty.servlet.ServletHandler.handle(
	at org.mortbay.jetty.servlet.SessionHandler.handle(
	at org.mortbay.jetty.handler.ContextHandler.handle(
	at org.mortbay.jetty.webapp.WebAppContext.handle(
	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(
	at org.mortbay.jetty.handler.HandlerCollection.handle(
	at org.mortbay.jetty.handler.HandlerWrapper.handle(
	at org.mortbay.jetty.Server.handle(
	at org.mortbay.jetty.HttpConnection.handleRequest(
	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(
	at org.mortbay.jetty.HttpParser.parseNext(
	at org.mortbay.jetty.HttpParser.parseAvailable(
	at org.mortbay.jetty.HttpConnection.handle(
	at org.mortbay.thread.BoundedThreadPool$

So, I think there's got to be some assumptions being made in one or more of the default search
components that's making it impossible to add a filter before it gets control.  Or maybe I'm
just tripping over a bug somewhere.

(FWIW, the version of Solr I am using is a nightly from mid-March.)


From: Wright Karl (Nokia-S/Cambridge)
Sent: Wednesday, April 28, 2010 6:40 PM
Subject: RE: Solr query question

Adding to the getFilters() list seems reasonable - although, to be fair, my code does seem
to work as intended when the component is added "last".  I'll do some experimentation and
see what model things work most consistently with.

TermRangeQuery doesn't seem to map readily to the functionality I'm looking for.  I basically
want to match documents that have no values for a specific field.  TermRange implies that
I know the potential set of values, and I don't at that point (unless I can use null or something
for the start/end strings in the range?)  Plus it is a Query, not a Filter, so if I use it
I'd also need to wrap it with FilterWrappedQuery or some such, no?  Is there any benefit in
using Query objects over Filter objects, or visa versa?  (I *am* trying to be sure that the
security filter does not affect relevance, for what it's worth...)


From: ext Erik Hatcher []
Sent: Wednesday, April 28, 2010 5:54 PM
Subject: Re: Solr query question

Rather than rewriting the original query, add a filter query (fq param
on the HTTP interface).  I think in the API you'll be using
rb.getFilters() and adding a filter to List returned.

Running your component last won't work (will it?), as it needs to be
run before the "query" component to take effect.

Re: WildcardFilter - I think you want TermRangeQuery there instead.


On Apr 28, 2010, at 5:35 PM, <> wrote:

> Turns out that, for the standard requestHandler, running this
> SearchComponent first causes its rewritten query to be lost.
> Running last fixed the problem.  (I'd *love* to know why that would
> be necessary.)
> But I'd still like comment as to whether the WildcardFilter
> construct is expected to be efficient in this context, or not. ;-)
> Karl
> ________________________________________
> From: Wright Karl (Nokia-S/Cambridge)
> Sent: Wednesday, April 28, 2010 2:57 PM
> To:
> Subject: Solr query question
> Hi Solr-knowledgeable folks,
> The LCF Solr SearchComponent plugin I'm developing doesn't quite
> work.  The query I'm trying to do is:
> -(allow_token_document:*) and -(deny_token_document:*) and <the
> user's search>
> The result I'm seeing is that everything in the user's search
> matches, unlike what I see in the admin UI, where the above query
> works perfectly.
> The code I'm using to do the negative wildcard searches is as follows:
>  public void prepare(ResponseBuilder rb) throws IOException
>  {
>      BooleanFilter bf = new BooleanFilter();
>      // No authenticated user name; only return 'public' documents
> (those with no security tokens at all)
>      // That query is:
>      // (fieldAllowShare is empty AND fieldDenyShare is empty AND
> fieldAllowDocument is empty AND fieldDenyDocument is empty)
>      // We're trying to map to:  -(fieldAllowShare:*) , which should
> be pretty efficient in Solr because it is negated.  If this turns
> out not to be so, then we should
>      // have the SolrConnector inject a special token into these
> fields when they otherwise would be empty, and we can trivially
> match on that token.
>      bf.add(new FilterClause(new WildcardFilter(new
> Term(fieldAllowDocument,"*")),BooleanClause.Occur.MUST_NOT));
>      bf.add(new FilterClause(new WildcardFilter(new
> Term(fieldDenyDocument,"*")),BooleanClause.Occur.MUST_NOT));
>     // Concatenate with the user's original query.
>     FilteredQuery query = new FilteredQuery(rb.getQuery(),bf);
>     rb.setQuery(query);
>  }
> Any hints welcome!
> Karl

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message