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
>> >> >
>> >>
>>
