Re: Filter by Type increases search results.
I have used fq the way it is with dismax and it works fine. fq is standard parameter and not specific to dismax. So type:idea should work correctly. - Preetam On Fri, Jul 18, 2008 at 11:30 AM, chris sleeman <[EMAIL PROTECTED]> wrote: > > btw, this *seems* to only work for me with standard search handler. > dismax > and fq: dont' seem to get along nicely... > > Wouldnt the dismax parser consider the filter query parameter as "type > idea" > and not value "idea" for solr field - "type"? > I guess thats the reason this query doesnt work with dismax, the way it > works with the standard search handler. You can add a "debugQuery=true" > parameter to check the actual parsed query. > > -Chris > > On Tue, Jul 15, 2008 at 10:47 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote: > > > On Tue, Jul 15, 2008 at 11:10 AM, Norberto Meijome <[EMAIL PROTECTED]> > > wrote: > > > On Tue, 15 Jul 2008 18:07:43 +0530 > > > "Preetam Rao" <[EMAIL PROTECTED]> wrote: > > > > > >> When I say filter, I meant q=fish&fq=type:idea > > > > > > btw, this *seems* to only work for me with standard search handler. > > dismax and fq: dont' seem to get along nicely... but maybe, it is just > late > > and i'm not testing it properly.. > > > > It should work the same... the only thing dismax does differently now > > is change the type of the base query to "dismax". > > > > -Yonik > > > > > > -- > Bill Cosby - "Advertising is the most fun you can have with your clothes > on." >
Re: Filter by Type increases search results.
I am not saying that fq parameter does not work with dismax. I am saying that the way this query is written it wont work because the dismax query handler would parse "type:idea" to a value "type idea" (without the colon) which changes the query. This would be a problem whether you use it in the main query or filter query. This standard search handler wont parse it this way and hence you would get different results depending on the handler used. On Fri, Jul 18, 2008 at 2:04 PM, Preetam Rao <[EMAIL PROTECTED]> wrote: > I have used fq the way it is with dismax and it works fine. > fq is standard parameter and not specific to dismax. > So type:idea should work correctly. > > - > Preetam > > On Fri, Jul 18, 2008 at 11:30 AM, chris sleeman <[EMAIL PROTECTED]> > wrote: > > > > btw, this *seems* to only work for me with standard search handler. > > dismax > > and fq: dont' seem to get along nicely... > > > > Wouldnt the dismax parser consider the filter query parameter as "type > > idea" > > and not value "idea" for solr field - "type"? > > I guess thats the reason this query doesnt work with dismax, the way it > > works with the standard search handler. You can add a "debugQuery=true" > > parameter to check the actual parsed query. > > > > -Chris > > > > On Tue, Jul 15, 2008 at 10:47 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote: > > > > > On Tue, Jul 15, 2008 at 11:10 AM, Norberto Meijome < > [EMAIL PROTECTED]> > > > wrote: > > > > On Tue, 15 Jul 2008 18:07:43 +0530 > > > > "Preetam Rao" <[EMAIL PROTECTED]> wrote: > > > > > > > >> When I say filter, I meant q=fish&fq=type:idea > > > > > > > > btw, this *seems* to only work for me with standard search handler. > > > dismax and fq: dont' seem to get along nicely... but maybe, it is just > > late > > > and i'm not testing it properly.. > > > > > > It should work the same... the only thing dismax does differently now > > > is change the type of the base query to "dismax". > > > > > > -Yonik > > > > > > > > > > > -- > > Bill Cosby - "Advertising is the most fun you can have with your clothes > > on." > > > -- Regards, Chris
Re: Filter by Type increases search results.
oops...my bad please ignore the previous comment. On Fri, Jul 18, 2008 at 6:07 PM, chris sleeman <[EMAIL PROTECTED]> wrote: > I am not saying that fq parameter does not work with dismax. > I am saying that the way this query is written it wont work because the > dismax query handler would parse "type:idea" to a value "type idea" (without > the colon) which changes the query. This would be a problem whether you use > it in the main query or filter query. > > This standard search handler wont parse it this way and hence you would get > different results depending on the handler used. > > > > On Fri, Jul 18, 2008 at 2:04 PM, Preetam Rao <[EMAIL PROTECTED]> > wrote: > >> I have used fq the way it is with dismax and it works fine. >> fq is standard parameter and not specific to dismax. >> So type:idea should work correctly. >> >> - >> Preetam >> >> On Fri, Jul 18, 2008 at 11:30 AM, chris sleeman <[EMAIL PROTECTED]> >> wrote: >> >> > > btw, this *seems* to only work for me with standard search handler. >> > dismax >> > and fq: dont' seem to get along nicely... >> > >> > Wouldnt the dismax parser consider the filter query parameter as "type >> > idea" >> > and not value "idea" for solr field - "type"? >> > I guess thats the reason this query doesnt work with dismax, the way it >> > works with the standard search handler. You can add a "debugQuery=true" >> > parameter to check the actual parsed query. >> > >> > -Chris >> > >> > On Tue, Jul 15, 2008 at 10:47 PM, Yonik Seeley <[EMAIL PROTECTED]> >> wrote: >> > >> > > On Tue, Jul 15, 2008 at 11:10 AM, Norberto Meijome < >> [EMAIL PROTECTED]> >> > > wrote: >> > > > On Tue, 15 Jul 2008 18:07:43 +0530 >> > > > "Preetam Rao" <[EMAIL PROTECTED]> wrote: >> > > > >> > > >> When I say filter, I meant q=fish&fq=type:idea >> > > > >> > > > btw, this *seems* to only work for me with standard search handler. >> > > dismax and fq: dont' seem to get along nicely... but maybe, it is just >> > late >> > > and i'm not testing it properly.. >> > > >> > > It should work the same... the only thing dismax does differently now >> > > is change the type of the base query to "dismax". >> > > >> > > -Yonik >> > > >> > >> > >> > >> > -- >> > Bill Cosby - "Advertising is the most fun you can have with your >> clothes >> > on." >> > >> > > > > -- > Regards, > Chris > -- Regards, Chris
Re: Distribution and restarting jetty
: pretty huge issue. Everytime I run the snapinstaller, it requires that : I restart jetty for the /admin/stats.jsp page to show items in the index : (I assume searches would also fail, but haven't tried). : : Once I restart, no problem. Does anyone have a solution for this? this message is a few weeks old, but I don't see any reply to it -- based on your description of hte problem, it sounds like snapinstaller is putting the snapshot in the right place, but failing to notify the solr port to use it -- that's done by having the snapinstaller script execute the commit script. what do the logs of your snapinstaller look like? you should see "notifing Solr to open a new Searcher" do you see any errors after that? what about in the log for hte commit script, doe it list any errors? -Hoss
Re: Filter query + holding previous Facet query counts
: Is there an easy way to use fq to filter down but retain the overall facet : query counts? I can't seem to find how to accomplish this but seems like a : common item needed for navigating though a result set. I need to do this w/o : holding a session and the counts always seem to reflect the current fq instead : of the overall lookup. Nope. the facet counts are always with respect to the DocSet that the returned DocList is a "slice" of. I imagine a subclass of FacetComponent that ignored the fq params when computing facet counts would be fairly simple to write. -Hoss
Re: Duplicate content
: > Is really unique if we allow duplicates? I had similar : > problem... : > : : if you allowDups, then uniqueKey may not be unique... allowDups is one of those features where Solr not only gives you enough rope to hang yourself, but Solr also ties the rope into a knot, cust some lumber, and builds you a gallows -- but it's a feature if what you really want to do is hang yourself. -Hoss
Issue with wt=javabin and multicore
I recently migrated from standard solr server to multicore implementation. I
observed that wt=javabin is failing with this error
java.lang.RuntimeException: This is a binary writer , Cannot write to a
characterstream
at
org.apache.solr.request.BinaryResponseWriter.write(BinaryResponseWriter.java:48)
I found that in org.apache.solr.servlet.SolrServlet.java, always PrintWriter
object is sent as input parameter.
This would fail if the ResponseWriter is of type BinaryResponseWriter.
{code}
QueryResponseWriter responseWriter = core.getQueryResponseWriter(solrReq);
response.setContentType(responseWriter.getContentType(solrReq, solrRsp));
PrintWriter out = response.getWriter();
responseWriter.write(out, solrReq, solrRsp);
{code}
Suggested change would be similar to as implemented in SolrDispatchFilter
{code}
response.setContentType(responseWriter.getContentType(solrReq, solrRsp));
QueryResponseWriter responseWriter = core.getQueryResponseWriter(solrReq);
if (Method.HEAD != reqMethod) {
if (responseWriter instanceof BinaryQueryResponseWriter) {
BinaryQueryResponseWriter binWriter =
(BinaryQueryResponseWriter) responseWriter;
binWriter.write(response.getOutputStream(), solrReq, solrRsp);
}else{
PrintWriter out = response.getWriter();
responseWriter.write(out, solrReq, solrRsp);
}
}
{code}
Any thoughts on this will be very valuable.
Thanks
Kalyan
Re: Issue with wt=javabin and multicore
I found that in org.apache.solr.servlet.SolrServlet.java, always PrintWriter object is sent as input parameter. SolrServlet is deprecated. If you are going to use new features like MultiCore, make sure you have the XmlUpdateRequestHandler registered to /update class="solr.XmlUpdateRequestHandler" />
