[
https://issues.apache.org/jira/browse/SOLR-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278697#comment-15278697
]
Mikhail Khludnev commented on SOLR-8208:
----------------------------------------
h2. TLDR
ok some notes about an attempt to use separate threads to invoke
EmbeddedSolrServer.
The first obstacle: it doesn't fully help to clean SolrRequestInfo. (and the
problem is that EmbeddedSolrServer can't be invoked from Solr threads where
SolrRequestInfo is set). So, even if we introduce thread pool to call
EmbeddedSolrServer, SolrRequestInfo.clear() should be called before, because
threadpool inherits SolrRequestInfo. Sic.
The real problem comes later: when randomized tests run. EmbeddedSolrServer
internals are larded with randomized flipping gears. So, when it requests a
randomized context, it's obtained from a mapping. But the key of this map is a
thread group, and DefaultSolrFactory assigns a thread group from the tread
which load the threadpool, but it was a thread pool used to launch the first
test in the suite, which usually finished already. That makes randomized
context unavailable for tests request EmbeddedSolrServer running later. That's
a bummer. No way. Don't do this ever.
> 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.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]
