Perfect - got it.
Now I know where I stand when I'm writing the bq, bf, etc...
Thank you very much.
On Thu, Jun 23, 2016 at 1:35 PM, Erick Erickson <erickerick...@gmail.com>
wrote:
> bq:
>
> My big question however is whether I can
> trust that the Boost Functions and
> Boost Query are running against the entire index
>
>
> In a word "no". The bf's are intended to alter
> the score of the documents found by the primary query
> by multiplying the function results by the raw score.
> If a document doesn't satisfy the primary
> query, it's score is zero so there's no point in dealing with
> the bf clauses. So the question of whether
> the bf's run against the entire index doesn't
> "make sense" in the Solr context.
>
> Another way of thinking about it is:
> "for all the docs that satisfy the primary query,
> multiply their score by the results of the bf
> specified".
>
> Best,
> Erick
>
>
> On Wed, Jun 22, 2016 at 3:04 PM, John Bickerstaff
> <j...@johnbickerstaff.com> wrote:
> > Oh - gotcha... Thanks for taking the time to reply. My use of the
> phrase
> > "sub query" is probably misleading...
> >
> > Here's the XML (below). I'm calling the Boost Query and Boost Function
> > statements "sub queries"...
> >
> > The thing I was referencing was this -- where I create an "alias" for the
> > query (titleQuery) and then use it in boost function on the next line...
> >
> > *<str name="titleQuery">{!edismax qf='title' bf='' bq='' v=$q}</str>*
> > *<str name="bf">product(query($titleQuery),4)</str>*
> >
> >
> > My big question however is whether I can trust that the Boost Functions
> and
> > Boost Query are running against the entire index (what I would prefer).
> >
> > The alternative (it seems to me) is that the default queryParser (edismax
> > in this case) gathers a primary data set and the subsequent queries ONLY
> > query on that set, not the entire index.
> >
> > I can't find documentation anywhere (so far) that covers things in that
> > depth... I am seeing some behavior in this requestHandler's results that
> > makes me wonder what happens under the covers...
> >
> >
> > =====
> >
> > BTW - That's a nice finesse move with the fq clause! I'll file that away
> > for future reference for sure...
> >
> > ====
> >
> > <requestHandler name="/syn" class="solr.SearchHandler">
> > <!-- default values for query parameters can be specified, these
> > will be overridden by parameters in the request
> > -->
> > <lst name="defaults">
> > <str name="echoParams">all</str>
> > <int name="rows">20</int>
> > <!-- Query settings -->
> >
> > <str name="defType">edismax</str>
> > <str name="q.alt">*:*</str>
> > <str name="rows">20</str>
> > <str name="fq">meta_doc_type:chapterDoc</str>
> > <str name="fl">id category_weight title category_ss score
> > contentType</str>
> >
> > *I'm calling the things below "sub queries" but that may be
> misleading...?*
> >
> > *<str name="bq">{!synonym_edismax qf='text' synonyms='true'
> > synonyms.originalBoost='1.2' *
> > * synonyms.synonymBoost='1.1' bf=''
> > bq='' v=$q}</str>*
> >
> > * <str name="titleQuery">{!edismax qf='title' bf='' bq=''
> v=$q}</str>*
> > * <str name="bf">product(query($titleQuery),4)</str>*
> > * <str name="bf">product(field(category_weight),20)</str>*
> > * <str name="qf">text contentType^1000</str>*
> >
> > <str name="wt">python</str>
> > <str name="debug">true</str>
> > <str name="debug.explain.structured">true</str>
> > <str name="indent">true</str>
> > <str name="echoParams">all</str>
> >
> > On Wed, Jun 22, 2016 at 2:34 PM, Erick Erickson <erickerick...@gmail.com
> >
> > wrote:
> >
> >> John:
> >>
> >> I'm not objecting to the XML, but to the very presence of "more than
> >> one query in a request handler". Request handlers don't have, AFAIK,
> >> "query chains". They have a list of defaults for the _single_ query
> >> being sent at a time to that handler. So having
> >>
> >> <str name="Query1"> blah blah </str>
> >>
> >> is something I've never seen before, thus my weaseling that it may be
> >> functionality that's new ;).
> >>
> >> And also, AFAIK, there's no real sense of query chaining except
> >> for the Rerank stuff.
> >>
> >> That said, if you do want to use the results of one query in another
> >> you can just put the whole thing into an fq clause (perhaps with
> >> {!cache=false}. At that point you'd get back the top N does
> >> that made it through the fq clause in score order.
> >>
> >> Best,
> >> Erick
> >>
> >> On Wed, Jun 22, 2016 at 3:20 PM, John Bickerstaff
> >> <j...@johnbickerstaff.com> wrote:
> >> > Hi Erick -
> >> >
> >> > I was trying to simplify and not waste anyone's time parsing my
> >> > requestHandler... That is, as you imply, bogus xml.
> >> >
> >> > The basic question is: If I have two "sub queries" in a single
> >> > requestHandler, do they both run independently against the entire
> index?
> >> >
> >> > Alternatively, is there some kind of "chain of results" whereby (a la
> >> SQL)
> >> > earlier result sets are passed to later subqueries and therefore those
> >> > later subqueries are ONLY looking at the results of earlier
> subqueries?
> >> >
> >> > I have always assumed the former (each subquery runs agains the entire
> >> > index) but I can't find documentation to prove it and I have some odd
> >> > behavior (that I won't go into here yet) that suggests something else
> is
> >> > happening...
> >> >
> >> > Oh - and thanks for the ReRanking mention! That sounds like it may be
> >> > quite useful!
> >> >
> >> > On Wed, Jun 22, 2016 at 12:08 AM, Erick Erickson <
> >> erickerick...@gmail.com>
> >> > wrote:
> >> >
> >> >> Where are you seeing that this does anything? It wouldn't be the
> first
> >> time
> >> >> new functionality happened that I totally missed, but I've never seen
> >> that
> >> >> config.
> >> >>
> >> >> You might get some mileage out of ReRankingQParserPlugin though, that
> >> runs
> >> >> the top N queries from one query through another.
> >> >>
> >> >> Best,
> >> >> Erick
> >> >> On Jun 21, 2016 2:43 PM, "John Bickerstaff" <
> j...@johnbickerstaff.com>
> >> >> wrote:
> >> >>
> >> >> > Hi all,
> >> >> >
> >> >> > I have a question about whether sub-queries in Solr
> requestHandlers go
> >> >> > against the total index or against the results of the previous
> query.
> >> >> >
> >> >> > Here's a simple example:
> >> >> >
> >> >> > <requestHandler name="/test1" class="solr.SearchHandler">
> >> >> >
> >> >> > <str name="Query1"> {!edismax qf=blah, blah}</str>
> >> >> >
> >> >> > <str name="Query2"> {!edismax qf=blah, blah}</str>
> >> >> >
> >> >> > </requestHandler>
> >> >> >
> >> >> > My question is:
> >> >> >
> >> >> > What does Query2 run "against"?
> >> >> > a. The entire Solr Index
> >> >> > b. The results of Query1
> >> >> >
> >> >> > If this is clearly documented anywhere, I'm very interested in a
> link.
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >>
> >>
>
