Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      Inspired by a conversation i had with someone on IRC a while back about using "append" fq params + local params to create custom request params, it occurred to me that it would be handy to have a "switch" qparser that could be configured with some set of fixed "switch case" localparams that it would delegate too based on it's input string.

        Activity

        Hide
        Hoss Man added a comment -

        Patch for review (includes docs & tests).

        some example usages straight from javadocs...

         In the examples below, the result of each query would be XXX....
        
         q = {!switch s.foo=XXX s.bar=zzz s.yak=qqq}foo
         q = {!switch s.foo=qqq s.bar=XXX s.yak=zzz} bar     // extra whitespace
         q = {!switch defSwitch=XXX s.foo=qqq s.bar=zzz}asdf // fallback on defSwitch
         q = {!switch s=XXX s.bar=zzz s.yak=qqq}             // blank input
        

        A practical usage of this QParsePlugin, is in specifying "appends" fq params in the configuration of a SearchHandler, to provide a fixed set of filter options for clients using custom parameter names. Using the example configuration below, clients can optionally specify the custom parameters in_stock and shipping to override the default filtering behavior, but are limited to the specific set of legal values (shipping=any|free, in_stock=yes|no|all).

         <requestHandler name="/select" class="solr.SearchHandler">
           <lst name="defaults">
             <str name="in_stock">yes</str>
             <str name="shipping">any</str>
           </lst>
           <lst name="appends">
             <str name="fq">{!switch s.all='*:*'
                                     s.yes='inStock:true'
                                     s.no='inStock:false'
                                     v=$in_stock}</str>
             <str name="fq">{!switch s.any='*:*'
                                     s.free='shipping_cost:0.0'
                                     v=$shipping}</str>
           </lst>
         </requestHandler>
        
        Show
        Hoss Man added a comment - Patch for review (includes docs & tests). some example usages straight from javadocs... In the examples below, the result of each query would be XXX.... q = {!switch s.foo=XXX s.bar=zzz s.yak=qqq}foo q = {!switch s.foo=qqq s.bar=XXX s.yak=zzz} bar // extra whitespace q = {!switch defSwitch=XXX s.foo=qqq s.bar=zzz}asdf // fallback on defSwitch q = {!switch s=XXX s.bar=zzz s.yak=qqq} // blank input A practical usage of this QParsePlugin, is in specifying "appends" fq params in the configuration of a SearchHandler, to provide a fixed set of filter options for clients using custom parameter names. Using the example configuration below, clients can optionally specify the custom parameters in_stock and shipping to override the default filtering behavior, but are limited to the specific set of legal values (shipping=any|free, in_stock=yes|no|all). <requestHandler name= "/select" class= "solr.SearchHandler" > <lst name= "defaults" > <str name= "in_stock" >yes</str> <str name= "shipping" >any</str> </lst> <lst name= "appends" > <str name= "fq" >{! switch s.all='*:*' s.yes='inStock: true ' s.no='inStock: false ' v=$in_stock}</str> <str name= "fq" >{! switch s.any='*:*' s.free='shipping_cost:0.0' v=$shipping}</str> </lst> </requestHandler>
        Hide
        Hoss Man added a comment -

        I'd appreciate any feedback on this idea, particularly the user API ("s", "s.*", and "defSwitch" .. not super stoked about "defSwitch" but i couldn't think of a better name)

        I also wrote a blog post with some background about where this idea came from...

        http://searchhub.org/2013/02/20/custom-solr-request-params/

        Show
        Hoss Man added a comment - I'd appreciate any feedback on this idea, particularly the user API ("s", "s.*", and "defSwitch" .. not super stoked about "defSwitch" but i couldn't think of a better name) I also wrote a blog post with some background about where this idea came from... http://searchhub.org/2013/02/20/custom-solr-request-params/
        Hide
        Hoss Man added a comment -

        Feedback from jan on twitter...

        Looks good, or a more verbose: {!switch case.yes='inStock:true' default='foo'}, or c.yes='…' where c short for case?

        I think using "case" instead of "s" and "default" instead of "defSwitch" makes a lot of sense ... my initial thinking was that the parser could consult both the localparams and the request params (before i realized that was too risky because clients could define their own cases) so i wanted the param names to be clearly related to "switch".

        My chief concern is about the difference between the "blank" case, and the "default" case when nothing matches, and wether people will be confused by the difference in meaning. ie: is it obvious to folks at a glance what each of these produce...

        {!switch case=XXX case.foo=YYY case=ZZZ default=QQQ v='    '}              // XXX
        {!switch case=XXX case.foo=YYY case=ZZZ default=QQQ v='case'}              // QQQ
        

        ...is that confusing? would it perhaps be better to have an explicit "blank" (or "empty" param name instead of using "case" as both a prefix & a param?

        Show
        Hoss Man added a comment - Feedback from jan on twitter... Looks good, or a more verbose: {!switch case.yes='inStock:true' default='foo'}, or c.yes='…' where c short for case? I think using "case" instead of "s" and "default" instead of "defSwitch" makes a lot of sense ... my initial thinking was that the parser could consult both the localparams and the request params (before i realized that was too risky because clients could define their own cases) so i wanted the param names to be clearly related to "switch". My chief concern is about the difference between the "blank" case, and the "default" case when nothing matches, and wether people will be confused by the difference in meaning. ie: is it obvious to folks at a glance what each of these produce... {!switch case=XXX case.foo=YYY case=ZZZ default=QQQ v=' '} // XXX {!switch case=XXX case.foo=YYY case=ZZZ default=QQQ v='case'} // QQQ ...is that confusing? would it perhaps be better to have an explicit "blank" (or "empty" param name instead of using "case" as both a prefix & a param?
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] Chris M. Hostetter
        http://svn.apache.org/viewvc?view=revision&revision=1449809

        SOLR-4481: SwitchQParserPlugin registered by default as 'switch'

        Show
        Commit Tag Bot added a comment - [trunk commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revision&revision=1449809 SOLR-4481 : SwitchQParserPlugin registered by default as 'switch'
        Hide
        Hoss Man added a comment -

        I went ahead and committed a version using the following syntax...

        {!switch case=XXX case.foo=YYY case.bar=ZZZ default=QQQ}foo
        

        Committed revision 1449809.
        Committed revision 1449823.

        Show
        Hoss Man added a comment - I went ahead and committed a version using the following syntax... {!switch case=XXX case.foo=YYY case.bar=ZZZ default=QQQ}foo Committed revision 1449809. Committed revision 1449823.
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] Chris M. Hostetter
        http://svn.apache.org/viewvc?view=revision&revision=1449823

        SOLR-4481: SwitchQParserPlugin registered by default as 'switch' (merge r1449809)

        Show
        Commit Tag Bot added a comment - [branch_4x commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revision&revision=1449823 SOLR-4481 : SwitchQParserPlugin registered by default as 'switch' (merge r1449809)
        Hide
        Uwe Schindler added a comment -

        Closed after release.

        Show
        Uwe Schindler added a comment - Closed after release.

          People

          • Assignee:
            Hoss Man
            Reporter:
            Hoss Man
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development