[
https://issues.apache.org/jira/browse/SOLR-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-8208:
-----------------------------------
Attachment: SOLR-8208-distrib-test-fix.patch
seting resonable numbers for {{createCollection(people, 2, 1, 10);}}
[^SOLR-8208-distrib-test-fix.patch]
> DocTransformer executes sub-queries
> -----------------------------------
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
> Issue Type: Improvement
> Components: Response Writers
> Reporter: Mikhail Khludnev
> Assignee: Mikhail Khludnev
> Labels: features, newbie
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8208-distrib-test-fix.patch, SOLR-8208.diff,
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch,
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch,
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch,
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch,
> SOLR-8208.patch, SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via
> doctransformer. I suppose it isn't query-time join specific, thus let to
> specify any query and parameters for them, let's call it sub-query. But it
> might be problematic to escape subquery parameters, including local ones,
> e.g. what if subquery needs to specify own doctransformer in &fl=\[..\] ?
> I suppose we can specify subquery parameter prefix:
> {code}
> ..&q=name_s:john&fl=*,depts:[subquery fromIndex=departments]&
> depts.q={!term f=dept_id_s
> v=$row.dept_ss_dv}&depts.fl=text_t,dept_id_s_dv&depts.rows=12&depts.sort=id
> desc
> {code}
> response is like
> {code}
> <response>
> ...
> <result name="response" numFound="1" start="0">
> <doc>
> <str name="id">1</str>
> <str name="name_s_dv">john</str>
> ..
> <result name="depts" numFound="2" start="0">
> <doc>
> <str name="dept_id_s_dv">Engineering</str>
> <str name="text_t">These guys develop stuff</str>
> </doc>
> <doc>
> <str name="dept_id_s_dv">Support</str>
> <str name="text_t">These guys help users</str>
> </doc>
> </result>
> </doc>
> </result>
> </response>
> {code}
> * {{fl=depts:\[subquery]}} executes a separate request for every query result
> row, and adds it into a document as a separate result list. The given field
> name (here it's 'depts') is used as a prefix to shift subquery parameters
> from main query parameter, eg {{depts.q}} turns to {{q}} for subquery,
> {{depts.rows}} to {{rows}}.
> * document fields are available as implicit parameters with prefix {{row.}}
> eg. if result document has a field {{dept_id}} it can be referred as
> {{v=$row.dept_id}} this combines well with \{!terms} query parser
> * {{separator=','}} is used when multiple field values are combined in
> parameter. eg. a document has multivalue field {code}dept_ids={2,3}{code},
> thus referring to it via {code}..&dept.q={!terms f=id
> v=$row.dept_ids}&..{code} executes a subquery {code}{!terms f=id}2,3{code}.
> When omitted it's a comma.
> * {{fromIndex=othercore}} optional param allows to run subquery on other
> core, like it works on query time join
> However, it doesn't work on cloud setup (and will let you know), but it's
> proposed to use regular params ({{collection}}, {{shards}} - whatever, with
> subquery prefix as below ) to issue subquery to a collection
> {code}
> q=name_s:dave&indent=true&fl=*,depts:[subquery]&rows=20&
> depts.q={!terms f=dept_id_s v=$row.dept_ss_dv}&depts.fl=text_t&
> depts.indent=true&
> depts.collection=departments&
> depts.rows=10&depts.logParamsList=q,fl,rows,row.dept_ss_dv
> {code}
> Caveat: it should be a way slow; it handles only search result page, not
> entire result set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
