You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Jason Gerlowski (Jira)" <ji...@apache.org> on 2021/04/15 12:50:00 UTC

[jira] [Commented] (SOLR-15308) ScoreJoinQParserPlugin chooses wrong Index when nesting more than 1 cross-index join query

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

Jason Gerlowski commented on SOLR-15308:
----------------------------------------

Hey [~mhov] - I think I can guess what the answer is, but what's the end result of the query being parsed this way?  Does the query return the right results, but inefficiently?  Does it return the wrong results entirely because it's using the wrong core at places?  Or does it have some other effect altogether?

> ScoreJoinQParserPlugin chooses wrong Index when nesting more than 1 cross-index join query
> ------------------------------------------------------------------------------------------
>
>                 Key: SOLR-15308
>                 URL: https://issues.apache.org/jira/browse/SOLR-15308
>             Project: Solr
>          Issue Type: Bug
>          Components: query parsers, SearchComponents - other
>    Affects Versions: 8.8.1
>         Environment: ubuntu 20.04, SOLR 8.8.1
>            Reporter: Matt Hov
>            Priority: Minor
>              Labels: JOIN, join, parser, scorer
>
> In this situation i have 2 cores "nodes" and "edges" and I wish to join across them WITH the performance enhancements of the "score=none" join param.
> If I debug the following query (get me the child nodes of a child nodes of parentid:1, joined back to nodes core)
> {code:java}
> /solr/nodes/select?q=*:*&debugQuery=true
> &fq={!join from=childid to=id score=none fromIndex=edges v=$q2}
> &q0=parentid:1
> &q1={!join from=childid to=parentid score=none fromIndex=edges v=$q0}
> &q2={!join from=childid to=parentid score=none fromIndex=edges v=$q1}
> &rows=0
> {code}
> parsed_filter_queries shows the following 
> {code:java}
> OtherCoreJoinQuery(OtherCoreJoinQuery [fromIndex=edges, fromCoreOpenTime=608579757538032 extends SameCoreJoinQuery [fromQuery=SameCoreJoinQuery [fromQuery=SameCoreJoinQuery [fromQuery=parentid:1, fromField=childid, toField=parentid, scoreMode=None], fromField=childid, toField=parentid, scoreMode=None], fromField=childid, toField=id, scoreMode=None]])
> {code}
> Where all the nested joins are parsed as SameCoreJoinQuery, now I might expect that since the first join is the "edges" core (query is on "nodes"), that the child joins would be the Same core as the first OtherCoreJoinQuery parent query. However if you look at ScoreJoinQParserPlugin.java:159  (under SameCoreJoinQuery)
>  
> {code:java}
> @Override
> public Weight createWeight(IndexSearcher searcher, org.apache.lucene.search.ScoreMode scoreMode, float boost) throws IOException {
>   SolrRequestInfo info = SolrRequestInfo.getRequestInfo();
>   final Query jq = JoinUtil.createJoinQuery(fromField, true,
>       toField, fromQuery, info.getReq().getSearcher(), this.scoreMode);
>   return jq.rewrite(searcher.getIndexReader()).createWeight(searcher, scoreMode, boost);
> }
> {code}
> "info.getReq().getSearcher()" will always be the searcher for the main index/core "nodes" not the parent OtherCoreJoinQuery index "edges"
>  
> I noticed undocumented test params "TESTenforceSameCoreAsAnotherOne" and if I add them to each query 
> {code:java}
> /solr/nodes/select?q=*:*&debugQuery=true
> &fq={!join from=childid to=id score=none fromIndex=edges TESTenforceSameCoreAsAnotherOne=true v=$q2}
> &q0=parentid:1
> &q1={!join from=childid to=parentid score=none fromIndex=edges TESTenforceSameCoreAsAnotherOne=true v=$q0}
> &q2={!join from=childid to=parentid score=none fromIndex=edges TESTenforceSameCoreAsAnotherOne=true v=$q1}
> &rows=0
> {code}
> I'll receive this parsed_filter_queries
> {code:java}
> OtherCoreJoinQuery(OtherCoreJoinQuery [fromIndex=edges, fromCoreOpenTime=608579757538032 extends SameCoreJoinQuery [fromQuery=OtherCoreJoinQuery [fromIndex=edges, fromCoreOpenTime=608579757538032 extends SameCoreJoinQuery [fromQuery=OtherCoreJoinQuery [fromIndex=edges, fromCoreOpenTime=608579757538032 extends SameCoreJoinQuery [fromQuery=parentid:1, fromField=childid, toField=parentid, scoreMode=None]], fromField=childid, toField=parentid, scoreMode=None]], fromField=childid, toField=id, scoreMode=None]])
> {code}
> which gives me what I'd expect and the correct results.  So I have this as a workaround in the meantime. 
> So I guess the solution depends on what you meant to happen, should a cross-index join under a cross-index join (of the same index) be a SameCoreJoinQuery?
> if that's the case then replace "info.getReq().getSearcher()" with "searcher" in SameCoreJoinQuery.createWeight(...)
> if it should be a OtherCoreJoinQuery like it's parent join query, then ScoreJoinQParserPlugin.java:228
> {code:java}
> final String myCore = req.getCore().getCoreDescriptor().getName();
> {code}
> should be getting the top level coreName from "SolrRequestInfo.getRequestInfo().getReq().getCore()"
>  
> Thanks
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org