Boosts can be included there too can't they? so this is valid?
q=+(stemmed^2:perl or stemmed^3:java) +unstemmed^5:"development manager" is it possible to have different boosts on the same field btw? We currently search across 5 fields anyway, so my queries are gonna start getting messy. :-/ --- IntelCompute Web Design & Local Online Marketing http://www.intelcompute.com On Wed, 30 Nov 2011 08:08:41 -0500, Erick Erickson <erickerick...@gmail.com> wrote: > You can't have multiple "q" clauses (as opposed to "fq" clauses). > You could form something like > q=unstemmed:perl or java&fq=stemmed:manager > or > q=+(unstemmed:perl or java) +stemmed:manager > > BTW, this fragment of the query probably doesn't do > what you expect: > unstemmed:perl or java > would be parsed as > unstemmed:perl OR default_search_field:java > > FWIW > Erick > > On Wed, Nov 30, 2011 at 7:39 AM, Rob Brown <r...@intelcompute.com> wrote: >> I guess I could do a bit of pre-processing, look for any words that are >> quoted, and search in a diff field for those >> >> How is a query like this formulated? >> >> q=unstemmed:perl or java&q=stemmed:manager >> >> >> -- >> >> IntelCompute >> Web Design and Online Marketing >> >> http://www.intelcompute.com >> >> >> -----Original Message----- >> From: Tomas Zerolo <tomas.zer...@axelspringer.de> >> Reply-to: solr-user@lucene.apache.org >> To: solr-user@lucene.apache.org >> Subject: Re: Don't snowball depending on terms >> Date: Wed, 30 Nov 2011 08:49:37 +0100 >> >> On Tue, Nov 29, 2011 at 01:53:44PM -0500, François Schiettecatte wrote: >>> It won't and depending on how your analyzer is set up the terms are most >>> likely stemmed at index time. >>> >>> You could create a separate field for unstemmed terms though, or use a less >>> aggressive stemmer such as EnglishMinimalStemFilterFactory. >> >> This is surprising to me. Snowball introduces new homonyms, meaning it >> will lump e.g. "management" and "manage" into one index entry. Thus, >> I'd expect a handful of "false positives" (but usually not too many). >> >> That's a "lossy index" (loosely speaking) and could be fixed by >> post-filtering (instead of introducing another index, which in >> most cases would seem a waste of resurces). >> >> Is there no way in SOLR of filtering the results *after* the index >> scan? I'd be disappointed! >> >> Regards >> -- tomás >>
