Solr
  1. Solr
  2. SOLR-407

Uncached filter query parameters

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: 1.3
    • Fix Version/s: 3.4, 4.0-ALPHA
    • Component/s: search
    • Labels:
      None

      Description

      Add a fq.nocache parameter (that may be specified multiple times) that adds filter clauses to the query which are not cached. Further, these filters are embedded directly into the BooleanQuery, which should be more efficient when filters are not reused.

        Activity

        Hide
        Mike Klaas added a comment -

        To implement I exposed one method of QueryUtils (getAbs) so that negative filters can be added as prohibited clauses.

        Show
        Mike Klaas added a comment - To implement I exposed one method of QueryUtils (getAbs) so that negative filters can be added as prohibited clauses.
        Hide
        Hoss Man added a comment -

        Mike: one thing that's not clear to me from a quick glance at your patch is wether or not this case works...

        q= -foo & fq.nocache=bar

        ...i think that in your patch, a boolean query containing one negative foo clause gets added to a new "target" query as a mandatory clause along with the fq.nocache ... and the SolrIndexSearcher code for detecting a pure negative query and finding the inverse doesn't get tripped.

        Show
        Hoss Man added a comment - Mike: one thing that's not clear to me from a quick glance at your patch is wether or not this case works... q= -foo & fq.nocache=bar ...i think that in your patch, a boolean query containing one negative foo clause gets added to a new "target" query as a mandatory clause along with the fq.nocache ... and the SolrIndexSearcher code for detecting a pure negative query and finding the inverse doesn't get tripped.
        Hide
        Mike Klaas added a comment -

        Good catch! This can be fixed in standard request handler as follows:

        if(null != ncFilters) {
        BooleanQuery target;
        if(query instanceof BooleanQuery)

        { target = (BooleanQuery)query; }

        else

        { target = new BooleanQuery(true); target.add(query, BooleanClause.Occur.MUST); }

        U.addFilters(ncFilters, target);
        query = target;
        }

        DisMax I don't think is a problem since it is adding to the top-level boolean query (can the dismax parser produce pure negative queries anyway?)

        I've fixed this with a test in my local copy. If we pursue this any further, I'll post a patch (also incorporating Yonik's localParams suggestion).

        Show
        Mike Klaas added a comment - Good catch! This can be fixed in standard request handler as follows: if(null != ncFilters) { BooleanQuery target; if(query instanceof BooleanQuery) { target = (BooleanQuery)query; } else { target = new BooleanQuery(true); target.add(query, BooleanClause.Occur.MUST); } U.addFilters(ncFilters, target); query = target; } DisMax I don't think is a problem since it is adding to the top-level boolean query (can the dismax parser produce pure negative queries anyway?) I've fixed this with a test in my local copy. If we pursue this any further, I'll post a patch (also incorporating Yonik's localParams suggestion).
        Hide
        Erik Hatcher added a comment -

        on my wishlist, targeting this for 1.5

        Show
        Erik Hatcher added a comment - on my wishlist, targeting this for 1.5
        Hide
        Hoss Man added a comment -

        Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

        http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

        Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

        A unique token for finding these 240 issues in the future: hossversioncleanup20100527

        Show
        Hoss Man added a comment - Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed. A unique token for finding these 240 issues in the future: hossversioncleanup20100527
        Hide
        Robert Muir added a comment -

        Bulk move 3.2 -> 3.3

        Show
        Robert Muir added a comment - Bulk move 3.2 -> 3.3
        Hide
        Robert Muir added a comment -

        3.4 -> 3.5

        Show
        Robert Muir added a comment - 3.4 -> 3.5
        Hide
        Koji Sekiguchi added a comment -

        Looks like it's been implemented as local parameter

        {!cache=false}

        .

        Show
        Koji Sekiguchi added a comment - Looks like it's been implemented as local parameter {!cache=false} .
        Hide
        Koji Sekiguchi added a comment -

        It's SOLR-2429. Resolved as duplicate.

        Show
        Koji Sekiguchi added a comment - It's SOLR-2429 . Resolved as duplicate.

          People

          • Assignee:
            Koji Sekiguchi
            Reporter:
            Mike Klaas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development