[jira] [Created] (LUCENE-6503) QueryWrapperFilter discards the IndexReaderContext when delegating to the wrapped query

["Trejkaz (JIRA)" <ji...@apache.org>]

Trejkaz created LUCENE-6503:
-------------------------------

             Summary: QueryWrapperFilter discards the IndexReaderContext when delegating to the wrapped query
                 Key: LUCENE-6503
                 URL: https://issues.apache.org/jira/browse/LUCENE-6503
             Project: Lucene - Core
          Issue Type: Bug
          Components: core/search
    Affects Versions: 4.10.4
            Reporter: Trejkaz


Suppose I have a working {{Filter}} which depends on the context within the composite reader, e.g., one which has a global BitSet of the docs which match but needs to know the docBase and maxDoc for the individual reader in order to return the correct set to the caller.

This is wrapped into a {{ConstantScoreQuery}} in order to become part of a {{BooleanQuery}} tree.

At some other layer, the entire query tree is wrapped back into a {{QueryWrapperFilter}} by some other code which wants to cache the results as a Filter.

QueryWrapperFilter has code like this:

{code}
  @Override
  public DocIdSet getDocIdSet(final AtomicReaderContext context, final Bits acceptDocs) throws IOException {
    // get a private context that is used to rewrite, createWeight and score eventually
    final AtomicReaderContext privateContext = context.reader().getContext();
    final Weight weight = new IndexSearcher(privateContext).createNormalizedWeight(query);
    return new DocIdSet() {
      @Override
      public DocIdSetIterator iterator() throws IOException {
        return weight.scorer(privateContext, acceptDocs);
      }
      @Override
      public boolean isCacheable() { return false; }
    };
  }
{code}

The call to {{reader().getContext()}} returns an {{AtomicReaderContext}} whose parent is not correctly set.

This is then passed to {{Weight#scorer}} which eventually arrives at {{ConstantScoreQuery#scorer}}, which calls {{Filter#getDocIdSet}}.

So our innermost {{Filter}} receives an {{AtomicReaderContext}} whose top-level {{IndexReader}} is not the actual top-level reader. This was detected in our code because we use a special subclass of DirectoryReader for our top-level reader and thus the filter failed. (Had it not failed, it would have silently returned the wrong results.)

The fix I have applied locally is to change the call to:

{code}
        return weight.scorer(context, acceptDocs);
{code}

This does appear to be working, but I'm not really sure if it's OK to build the IndexSearcher using one context while passing another context to the scorer.




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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org