[
https://issues.apache.org/jira/browse/SOLR-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-8208:
-----------------------------------
Description:
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 aseparate 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.
was:
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 them 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 allow to 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}
* {{paramPrefix=subq1.}} shifts parameters for subquery: {{subq1.q}} turns to
{{q}} for subquery, {{subq1.rows}} to {{rows}}
* {{separator=','}}
* {{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 let you know), but it's proposed
to 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}
* the itchiest one is to reference to document field from subquery parameters,
here I propose to use local param {{v}} and param deference {{v=$param}} thus
every document field implicitly introduces parameter for subquery
$\{paramPrefix\}row.$\{fieldName\}, thus above subquery is
q=child_id:<doc.getField("id")>, presumably we can drop "row." in the middle
(reducing to v=$subq1.id), until someone deal with {{rows}}, {{sort}} fields.
* \[subquery\], or \[query\], or ?
Caveat: it should be a way slow; it handles only search result page, not entire
result set.
> DocTransformer executes sub-queries
> -----------------------------------
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
> Issue Type: Improvement
> Reporter: Mikhail Khludnev
> Assignee: Mikhail Khludnev
> Labels: features, newbie
> Attachments: 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
>
>
> 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 aseparate 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
