Re: Any way to get reference to original request object from within Solr component?
One way to do this is to register a servlet filter that places the current request in a global static ThreadLocal variable, thereby making it available to your Solr component. It's kind of a hack but would work. Sent from my phone On Mar 17, 2012, at 6:53 PM, "SUJIT PAL" wrote: > Thanks Pravesh, > > Yes, converting the myparam to a single (comma-separated) field is probably > the best approach, but as I mentioned, this is probably a bit too late for > this to be practical in my case... > > The myparam parameters are facet filter queries, and so far order did not > matter, since the filters were just AND-ed together and applied to the result > set and facets were being returned in count order. But now the requirement is > to "bubble up" the selected facets so the one is most currently selected is > on the top. This was uncovered during user-acceptance testing (since the > client shows only the top N facets, and the currently selected facet to > disappear since its no longer within the top N facets). > > Asking the client to switch to a single comma-separated field is an option, > but its the last option at this point, so I was wondering if it was possible > to switch to some other data structure, or at least get a handle to the > original HTTP servlet request from within the component so I could grab the > parameters from there. > > I noticed that the /select call does preserve the order of the parameters, > but that is because its probably being executed by SolrServlet, which gets > its parameters from the HttpServletRequest. > > I guess I will have to just run the request through a debugger and see where > exactly the parameter order gets messed up...I'll update this thread if I > find out. > > Meanwhile, if any of you have simpler alternatives, would really appreciate > knowing... > > Thanks, > -sujit > > On Mar 17, 2012, at 12:01 AM, pravesh wrote: > >> Hi Sujit, >> >> The Http parameters ordering is above the SOLR level. Don't think this could >> be controlled at SOLR level. >> You can append all required values in a single Http param at then break at >> your component level. >> >> Regds >> Pravesh >> >> -- >> View this message in context: >> http://lucene.472066.n3.nabble.com/Any-way-to-get-reference-to-original-request-object-from-within-Solr-component-tp3833703p3834082.html >> Sent from the Solr - User mailing list archive at Nabble.com. >
Re: Knowing which fields matched a search
Paul, I would think debugQuery would make it slower too, wouldn't it? Where is the thread you are referring to? Is there a lucene jira ticket for this? On Mar 11, 2012, at 9:38 AM, Paul Libbrecht wrote: > Russel, > > there's been a thread on that in the lucene world... it's not really perfect > yet. > The suggestion to debugQuery gives only, to my experience, the explain > monster which is good for developers (only). > > paul > > > Le 11 mars 2012 à 08:40, William Bell a écrit : > >> debugQuery tells you. >> >> On Fri, Mar 9, 2012 at 1:05 PM, Russell Black wrote: >>> When searching across multiple fields, is there a way to identify which >>> field(s) resulted in a match without using highlighting or stored fields? >> >> >> >> -- >> Bill Bell >> billnb...@gmail.com >> cell 720-256-8076 >
Knowing which fields matched a search
When searching across multiple fields, is there a way to identify which field(s) resulted in a match without using highlighting or stored fields?
Re: Auto-warming for new indexes
I answered my own question after some digging on the code. The caches are structured as maps. In the cases I looked at, auto-warming ignores the values in the map. Instead, it uses the map's keys (usually a query) to perform and cache a search result in the new searcher. On Mar 7, 2012, at 2:51 PM, Russell Black wrote: > As I understand it, auto-warming is the process of populating a new > searcher's caches from cached objects in the old searcher's caches. Let's > say that a new searcher is created to service a new index that came from > replication. Because the new searcher is operating on a new index, how is it > possible that caches from the old index can be valid for the new index? > Records could have been added, removed or changed in the new index. It seems > like this would invalidate the old caches. What am I missing? > > >
Auto-warming for new indexes
As I understand it, auto-warming is the process of populating a new searcher's caches from cached objects in the old searcher's caches. Let's say that a new searcher is created to service a new index that came from replication. Because the new searcher is operating on a new index, how is it possible that caches from the old index can be valid for the new index? Records could have been added, removed or changed in the new index. It seems like this would invalidate the old caches. What am I missing?
frange with multi-valued fields
Has anyone had experience using frange with multi-valued fields? In solr 3.5 doing so results in the error: "can not use FieldCache on multivalued field" Here's the use case. We have multiple years attached to each document and want to be able to refine by a year range. We're currently using the standard range query syntax [ 1900 TO 1910 ] which works, but those queries are slower than we would like. I've seen reports that using frange can greatly improve performance. http://solr.pl/en/2011/05/30/quick-look-frange/ >From what I can tell, there seem to be efforts in 4.0 to allow functions to >work on multivalued fields. Does anyone know for sure? Thanks, Russ
