[ 
https://issues.apache.org/jira/browse/SOLR-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057857#comment-15057857
 ] 

Upayavira commented on SOLR-8208:
---------------------------------

This is useful stuff. Much needed. I assume this would work as well on block 
joins and alongside pseudo joins, which I think I'm seeing above?

Traditionally, in a local params query parser, the parameter v refers to the 
actual query string, so: {code}q={!lucene v=$qq}&qq=field:(my search) {code} 
would be a valid syntax. I would suggest using n= (for name) or tag= for the 
field name of the newly created field to avoid association with this v= syntax.

Is a lookup based upon the ID of a field in the current document sufficient? I 
suspect it is.

Do you also support fromIndex - that is, executing the query against another 
core or collection? *That* would be the killer feature.

As to the fq={!tag=join}{!join blah....} syntax, if you had [subquery fq=join], 
you wouldn't actually execute the join query, you would just locate the query 
object, and extract its key parameters to avoid the user from having to enter 
them multiple times. Having both options would be super cool.

> DocTransformer executes sub-queries
> -----------------------------------
>
>                 Key: SOLR-8208
>                 URL: https://issues.apache.org/jira/browse/SOLR-8208
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Mikhail Khludnev
>              Labels: features, newbie
>         Attachments: 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 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}
> ..&fl=id,[subquery paramPrefix=subq1. 
> fromIndex=othercore],score,..&subq1.q={!term f=child_id 
> v=$subq1.row.id}&subq1.rows=3&subq1.sort=price&..
> {code}       
> * {{paramPrefix=subq1.}} shifts parameters for subquery: {{subq1.q}} turns to 
> {{q}} for subquery, {{subq1.rows}} to {{rows}}
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> * 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. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to