Re: Result docs missing only when shards parameter present in query?

Does this seem like it would be a configuration issue, an indexed data issue, or something else? Thanks mrw wrote: > > We have two Solr nodes, each with multiple shards. If we query each shard > directly (no shards parameter), we get the expected results: > > respons

Result docs missing only when shards parameter present in query?

We have two Solr nodes, each with multiple shards. If we query each shard directly (no shards parameter), we get the expected results: response lst name="responseHeader" int name="status" 0 int name="QTime" 22 result name="response" numFound="100" start="0" d

Re: Dismax: field not returned unless in sort clause?

No, not setting those options in the query or schema.xml file. I'll try what you said, however. Thanks Chris Hostetter-3 wrote: > > : We have a "D" field (string, indexed, stored, not required) that is > returned > : * when we search with the standard request handler > : * when we search with

Dismax: field not returned unless in sort clause?

We have a "D" field (string, indexed, stored, not required) that is returned * when we search with the standard request handler * when we search with dismax request handler _and the field is specified in the sort parameter_ but is not returned when using the dismax handler and the field is not spe

Re: Dismax, q, q.alt, and defaultSearchField?

> -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > On 2. mars 2011, at 23.06, mrw wrote: > >> We have two banks of Solr nodes with identical schemas. The data I'm >> searching for is in both banks. >> >> One has defa

RE: Understanding multi-field queries with q and fq

gt; > Have you looked at the 'qf' parameter? > > Bob Sandiford | Lead Software Engineer | SirsiDynix > P: 800.288.8020 X6943 | bob.sandif...@sirsidynix.com > www.sirsidynix.com  > _ > http://www.cosugi.org/  > > > > >> -Original Message- >&

Re: Solr Admin Interface, reworked - Go on? Go away?

take queries from the logs, split them around parameters, take the shards out, put the shards back in, take the OLS labels out, put them back in, etc. With long, complex queries, it's essential to have a large work space to play in. :) Stefan Matheis wrote: > > mrw, > > you

Dismax, q, q.alt, and defaultSearchField?

We have two banks of Solr nodes with identical schemas. The data I'm searching for is in both banks. One has defaultSearchField set to field1, the other has defaultSearchField set to field2. We need to support both user queries and facet queries that have no user content. For the latter, it app

Re: Solr Admin Interface, reworked - Go on? Go away?

Looks nice. Might be also worth it to create a page with large query field for pasting in complete URL-encoded queries that cross cores, etc. I did that at work (via ASP.net) so we could paste in queries from logs and debug them. We tend to use that quite a bit. Cheers Stefan Matheis wrote:

Re: dismax query with no/empty/*:* q parameter?

Ah...so I need to be doing &q.alt=*:* &fq=:. Of course, now that you showed me what I look for, I also see the explanation in the Packt book. Sheesh. Thanks for the tip! Chris Hostetter-3 wrote: > > : For standard query handler fq-only queries, we used q=*:*. However, > with > : dismax, t

Re: Understanding multi-field queries with q and fq

ser's query to multiple fields, so if the user enters "led zeppelin merle" we need to be able to do the logical equivalent of &fq=field1:led zeppelin merle OR field2:led zeppelin merle Any ideas? :) mrw wrote: > > After searching this list, Google, and looking t

dismax query with no/empty/*:* q parameter?

For standard query handler fq-only queries, we used q=*:*. However, with dismax, that returns 0 results. Are fq-only queries possible with dismax? Thanks! -- View this message in context: http://lucene.472066.n3.nabble.com/dismax-query-with-no-empty-q-parameter-tp2619170p2619170.html Sen

RE: Disabling caching for fq param?

cific > fq's end up falling off the back as least-recently-used. > > So in actual practice, one way or another, it may not be a problem. > > From: mrw [mikerobertsw...@gmail.com] > Sent: Monday, February 28, 2011 9:06 PM > To: solr-u

Re: Disabling caching for fq param?

We use fq params for filtering as well (not show in previous example), so we only want to be able to override fq caching on a per-parameter basis (e.g., fq={!noCache userLabels} ). Thanks Markus Jelsma-2 wrote: > > If filterCache hitratio is low then just disable it in solrconfig by > deleting

Disabling caching for fq param?

Based on what I've read here and what I could find on the web, it seems that each fq clause essentially gets its own results cache. Is that correct? We have a corporate policy of passing the user's Oracle OLS labels into the index in order to be matched against the labels field. I currently sepa

Re: Basic Dismax syntax question

wrote: > > > --- On Mon, 2/28/11, mrw wrote: > >> From: mrw >> Subject: Basic Dismax syntax question >> To: solr-user@lucene.apache.org >> Date: Monday, February 28, 2011, 7:41 PM >> Say I have an index with first_name >> and last_name fields, and also a cop

Re: Basic Dismax syntax question

t to lowercase the terms and/or the search > term? > > On Mon, Feb 28, 2011 at 10:41 AM, mrw wrote: > >> Say I have an index with first_name and last_name fields, and also a copy >> field for the full name called full_name. Say I add two employees: >> Napoleon Bonap

Basic Dismax syntax question

Say I have an index with first_name and last_name fields, and also a copy field for the full name called full_name. Say I add two employees: Napoleon Bonaparte and Napoleon Dynamite. If I search for just the first or last name, or both names, with mm=1, I get the expected results: q=Napoleon&def

Re: Understanding multi-field queries with q and fq

I think we're stuck with moving the labels piece to q and the user query to fq and sticking with the standard handler. Thanks! Otis Gospodnetic-2 wrote: > > Hi mrw, > > It sounds like you (e)dismax is what you should look into. You didn't > mention > it/them, so

Understanding multi-field queries with q and fq

After searching this list, Google, and looking through the Pugh book, I am a little confused about the right way to structure a query. The Packt book uses the example of the MusicBrainz DB full of song metadata. What if they also had the song lyrics in English and German as files on disk, and w

Re: GET or POST for large queries?

Thanks for the tip. No, I did not know about that. Unfortunately, we use Oracle OLS which does not appear to be supported. Jan Høydahl / Cominvent wrote: > > Hi, > > There are better ways to combat row level security in search than sending > huge lists of users over the wire. > > Have you c

Re: GET or POST for large queries?

Thanks for the response and info. I'll try that. Jonathan Rochkind wrote: > > Yes, I think it's 1024 by default. I think you can raise it in your > config. But your performance may suffer. > > Best would be to try and find a better way to do what you want without > using thousands of cla

Re: GET or POST for large queries?

Thanks for the response. Yes, the queries are fairly large. Basically, the corporate security policy dictates that we use row-level security attributes from the DB for access control to Solr. So, we bake row-level security attributes from the database into the index, and then, at query time,

Re: GET or POST for large queries?

Yeah, I tried switching to POST. It seems to be handling the size, but apparently Solr has a limit on the number of boolean comparisons -- I'm now getting "too many boolean clauses" errors emanating from org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:108). :) Th

GET or POST for large queries?

We are running into some issues with large queries. Initially, they were ostensibly header buffer overruns, because increasing Jetty's headerBufferSize value to 65536 resolved them. This seems like a kludge, but it does solve the problem for 95% of our users. However, we do have queries that are

Re: Changing value of start parameter affects numFound?

mrw wrote: > > I have a data set indexed over two irons, with M docs per Solr core for a > total of N cores. > > If I perform a query across all N cores with start=0 and rows=30, I get, > say, numFound=27521). If I simply change the start param to start=27510 > (simulat

Changing value of start parameter affects numFound?

I have a data set indexed over two irons, with M docs per Solr core for a total of N cores. If I perform a query across all N cores with start=0 and rows=30, I get, say, numFound=27521). If I simply change the start param to start=27510 (simulating being on the last page of data), I get a smalle

Re: Adding fq to query with mincount=0 causes unexpected 0-count facet values to be returned?

mrw wrote: > > > We're actually using the default facet.limit value of 100. I will > increase it to 200 and see if the non-zero-count facets show up. Maybe > that was causing my confusion. > Yep -- the 0-count facets were not being returned due to the facet.limit

Re: Adding fq to query with mincount=0 causes unexpected 0-count facet values to be returned?

iorixxx wrote: > > > After re-reading, it is not normal that none of the 0-count facets are > showing up. Can you give us full parameter list that you obtain this > by adding &echoParams=all to your search URL? > > May be you limit facets to three in your first query? What happens when > you a

Re: Adding fq to query with mincount=0 causes unexpected 0-count facet values to be returned?

>> Notice how, before the fq clause is added, none of the >> 0-count facets are >> returned, even though facet.mincount = 0, but afterward, a >> bunch of 0-count >> facets are returned? >> > This is normal. What's behind that? Is it widening the results before the mincount constraint is being a

Adding fq to query with mincount=0 causes unexpected 0-count facet values to be returned?

I've noticed that performing a query with facet.mincount=0 and no fq clauses results in a response where only facets with non-zero counts are returned, but adding in an fq clause (caused by a user selecting a non-zero-valued facet value checkbox) actually causes a bunch of 0-count facet values com

Re: Different behavior for q=goo.com vs q=@goo.com in queries?

Basically, just what you've suggested. I did the field/query analysis piece with verbose output. Not entirely sure how to interpret the results, of course. Currently reading anything I can find on that. Thanks Erick Erickson wrote: > > What steps have you taken to figure out whether the >

Different behavior for q=goo.com vs q=@goo.com in queries?

Using Lucid's Solr 1.4 distribution, if I index my email inbox and then search it by passing in different email expressions, I notice that I get different results based on whether the '@' character is included, even though the character is present in every email address in the field I'm searching.