lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <karl.wri...@nokia.com>
Subject RE: Solr query question
Date Thu, 29 Apr 2010 00:16:57 GMT
Turns out that FilteredQuery is what is causing the issue in this case.  I removed FilteredQuery,
and instead constructed the search using Query objects instead of Filter objects, and everything
is happy now.

Karl

________________________________________
From: Wright Karl (Nokia-S/Cambridge)
Sent: Wednesday, April 28, 2010 7:32 PM
To: dev@lucene.apache.org; connectors-dev@incubator.apache.org
Subject: RE: Solr query question

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:

null

java.lang.NullPointerException
        at org.apache.lucene.search.FilteredQuery.hashCode(FilteredQuery.java:229)
        at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
        at org.apache.solr.common.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:87)
        at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:133)
        at org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:538)
        at org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:581)
        at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:903)
        at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:884)
        at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341)
        at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:178)
        at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195)
        at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
        at org.apache.solr.core.SolrCore.execute(SolrCore.java:1321)
        at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:244)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
        at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
        at org.mortbay.jetty.Server.handle(Server.java:285)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
        at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
        at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

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.)

Karl

________________________________________
From: Wright Karl (Nokia-S/Cambridge)
Sent: Wednesday, April 28, 2010 6:40 PM
To: dev@lucene.apache.org; connectors-dev@incubator.apache.org
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...)

Karl

________________________________________
From: ext Erik Hatcher [erik.hatcher@gmail.com]
Sent: Wednesday, April 28, 2010 5:54 PM
To: connectors-dev@incubator.apache.org
Cc: dev@lucene.apache.org
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.

        Erik



On Apr 28, 2010, at 5:35 PM, <karl.wright@nokia.com> 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: connectors-dev@incubator.apache.org
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message