Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-15308

ScoreJoinQParserPlugin chooses wrong Index when nesting more than 1 cross-index join query

    XMLWordPrintableJSON

    Details

      Description

      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)

      /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
      
      

      parsed_filter_queries shows the following 

      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]])
      

      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)

       

      @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);
      }
      

      "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 

      /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
      
      

      I'll receive this parsed_filter_queries

      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]])
      

      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

      final String myCore = req.getCore().getCoreDescriptor().getName();
      

      should be getting the top level coreName from "SolrRequestInfo.getRequestInfo().getReq().getCore()"

       

      Thanks

       

       

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mhov Matt Hov
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: