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: d...@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: d...@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.hatc...@gmail.com]
Sent: Wednesday, April 28, 2010 5:54 PM
To: connectors-dev@incubator.apache.org
Cc: d...@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.wri...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
