Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.4
    • Component/s: search
    • Labels:
      None

      Description

      plumbing to support the selection of multiple constraints in a facet

      1. SOLR-911.patch
        29 kB
        Yonik Seeley
      2. SOLR-911.patch
        28 kB
        Yonik Seeley
      3. SOLR-911.patch
        10 kB
        Yonik Seeley

        Activity

        Hide
        Yonik Seeley added a comment -

        OK, here's a prototype (still needs string-constants, distrib support, and tests) that implements support for multi-select facets by allowing the tagging of any query via the existing "localParams" syntax. It adds localParams support to facet commands like facet.field to allow exclusion of certain filters.

        fq=

        {!tag=typefilter}

        type:pdf&facet.field=

        {!ex=typefilter}

        myfield

        both tag and ex may be a comma separated list to allow storing under different tags and selecting multiple tags.

        The localParams method seems preferable since it can be arbitrarily extended for other controls, and already existed when parsing queries.

        This patch also adds the ability to specify a different output name/key... useful for complex facet queries:

        facet.query=

        {!key=foo}

        rng:[1 TO 2] OR rng:[5 TO 9]
        will cause the results to come back under a key of "foo" rather than "rng:[1 TO 2] OR rng:[5 TO 9]"

        Show
        Yonik Seeley added a comment - OK, here's a prototype (still needs string-constants, distrib support, and tests) that implements support for multi-select facets by allowing the tagging of any query via the existing "localParams" syntax. It adds localParams support to facet commands like facet.field to allow exclusion of certain filters. fq= {!tag=typefilter} type:pdf&facet.field= {!ex=typefilter} myfield both tag and ex may be a comma separated list to allow storing under different tags and selecting multiple tags. The localParams method seems preferable since it can be arbitrarily extended for other controls, and already existed when parsing queries. This patch also adds the ability to specify a different output name/key... useful for complex facet queries: facet.query= {!key=foo} rng: [1 TO 2] OR rng: [5 TO 9] will cause the results to come back under a key of "foo" rather than "rng: [1 TO 2] OR rng: [5 TO 9] "
        Hide
        Erik Hatcher added a comment - - edited

        facet.query={!key=foo}rng:[1 TO 2] OR rng:[5 TO 9]

        nice!

        Another goodie to overload into the local params is something maybe like

        {!nocache}

        to prevent filling up the filter cache with something that is not meant to be reused or often. There's another implementation over at SOLR-407.

        Show
        Erik Hatcher added a comment - - edited facet.query={!key=foo}rng: [1 TO 2] OR rng: [5 TO 9] nice! Another goodie to overload into the local params is something maybe like {!nocache} to prevent filling up the filter cache with something that is not meant to be reused or often. There's another implementation over at SOLR-407 .
        Hide
        Yonik Seeley added a comment -

        Whew, things got complicated in distributed search.... refinement queries need to keep the same exclusions so that they get the right count. I decided to implement a different approach that specifies a comma separated list of terms for the facet.field when refining. This should result in much smaller refinement requests, less parsing overhead, and smaller response sizes.

        Attaching latest draft... only thing left is to make some string constants I think.

        Show
        Yonik Seeley added a comment - Whew, things got complicated in distributed search.... refinement queries need to keep the same exclusions so that they get the right count. I decided to implement a different approach that specifies a comma separated list of terms for the facet.field when refining. This should result in much smaller refinement requests, less parsing overhead, and smaller response sizes. Attaching latest draft... only thing left is to make some string constants I think.
        Hide
        Yonik Seeley added a comment -

        Attaching finished patch.
        I'll wait a little while before committing to give time for others to review the API and suggest changes.

        Show
        Yonik Seeley added a comment - Attaching finished patch. I'll wait a little while before committing to give time for others to review the API and suggest changes.
        Hide
        Hoss Man added a comment -

        This patch also adds the ability to specify a different output name/key... useful for complex facet queries:

        facet.query={!key=foo}rng:[1 TO 2] OR rng:[5 TO 9]
        will cause the results to come back under a key of "foo" rather than "rng:[1 TO 2] OR rng:[5 TO 9]"

        but then how will the client know how what to filter on to actually constrain the query by "foo" since it won't actually ko what query that was?

        Show
        Hoss Man added a comment - This patch also adds the ability to specify a different output name/key... useful for complex facet queries: facet.query={!key=foo}rng: [1 TO 2] OR rng: [5 TO 9] will cause the results to come back under a key of "foo" rather than "rng: [1 TO 2] OR rng: [5 TO 9] " but then how will the client know how what to filter on to actually constrain the query by "foo" since it won't actually ko what query that was?
        Hide
        Yonik Seeley added a comment -

        but then how will the client know how what to filter on to actually constrain the query by "foo" since it won't actually ko what query that was?

        Well, it's optional... it's only an issue for stateless clients without conventions or application specific knowledge - and they could always look at the original parameters via echoParams.

        Show
        Yonik Seeley added a comment - but then how will the client know how what to filter on to actually constrain the query by "foo" since it won't actually ko what query that was? Well, it's optional... it's only an issue for stateless clients without conventions or application specific knowledge - and they could always look at the original parameters via echoParams.
        Hide
        Hoss Man added a comment -

        Well, it's optional... it's only an issue for stateless clients without conventions or application specific knowledge - and they could always look at the original parameters via echoParams.

        that assumes it wasn't baked into the config file.

        I guess there's no harm in adding it (except perhaps confusion: i'd hate to see people assume that they can add "fq=key" since they got "key" back in the facet_queries section of the response)

        my point was really just that facet constraint "labels" are really only useful if each label is easily associated with a way of applying that constraint. replacing the query string with a "key" in the response is only useful if that key can be used for something.

        It seems to me like it would be far more useful to just reserve "key" as a special local param that we guarantee will never get used, so people can include it in the facet.query and then parse it out of the response themselves.

        You can already do this today...

        In Config...
            <lst name="defaults">
              <str name="facet.query">{!ignoredparam="Low Price"}price:[* TO 500]</str>
              <str name="facet.query">{!ignoredparam="Hight Price"}price:[500 TO *]</str>
              ...
        In Query Response...
           <lst name="facet_queries">
             <int name="{!ignoredparam="Low Price"}price:[* TO 500]">3</int>
             <int name="{!ignoredparam="Hight Price"}price:[500 TO *]">0</int>
             ...
        

        ...but it would be nice to have a parma name reserved for this.

        (admittedly it never occurred to me until this Jira post that that worked, i'm going to start encouraging every one i know to start doing that)

        Show
        Hoss Man added a comment - Well, it's optional... it's only an issue for stateless clients without conventions or application specific knowledge - and they could always look at the original parameters via echoParams. that assumes it wasn't baked into the config file. I guess there's no harm in adding it (except perhaps confusion: i'd hate to see people assume that they can add "fq=key" since they got "key" back in the facet_queries section of the response) my point was really just that facet constraint "labels" are really only useful if each label is easily associated with a way of applying that constraint. replacing the query string with a "key" in the response is only useful if that key can be used for something. It seems to me like it would be far more useful to just reserve "key" as a special local param that we guarantee will never get used, so people can include it in the facet.query and then parse it out of the response themselves. You can already do this today... In Config... <lst name="defaults"> <str name="facet.query">{!ignoredparam="Low Price"}price:[* TO 500]</str> <str name="facet.query">{!ignoredparam="Hight Price"}price:[500 TO *]</str> ... In Query Response... <lst name="facet_queries"> <int name="{!ignoredparam="Low Price"}price:[* TO 500]">3</int> <int name="{!ignoredparam="Hight Price"}price:[500 TO *]">0</int> ... ...but it would be nice to have a parma name reserved for this. (admittedly it never occurred to me until this Jira post that that worked, i'm going to start encouraging every one i know to start doing that)
        Hide
        Yonik Seeley added a comment -

        Committed. I don't believe there are changes suggested to the API, just possible additions.
        We can iterate or improve before 1.4.

        Show
        Yonik Seeley added a comment - Committed. I don't believe there are changes suggested to the API, just possible additions. We can iterate or improve before 1.4.
        Hide
        Grant Ingersoll added a comment -

        Bulk close for Solr 1.4

        Show
        Grant Ingersoll added a comment - Bulk close for Solr 1.4

          People

          • Assignee:
            Unassigned
            Reporter:
            Yonik Seeley
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development