Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      It would be useful if one Solr request handler could inherit from another. Or perhaps a mixin style so multiple could be merged in. I've wanted to do this to reduce repeating myself in solrconfig.xml RH configurations. Maybe all that's needed is one RH which provides the defaults to all the other search handlers. This feature could also be useful for establishing some defaults like for "df" and "q.op" and "f.myfieldname.facet.method".

        Issue Links

          Activity

          Hide
          Jan Høydahl added a comment -

          Let's explore this. I use request handler configs extensively for defining various search use cases, and they frequently share a considerable number of settings. Perhaps a simple <requestHandler name="foo" extends="bar"...> syntax would do? Then we could get pretty one-liners if just one parameter changes from the parent.

          Show
          Jan Høydahl added a comment - Let's explore this. I use request handler configs extensively for defining various search use cases, and they frequently share a considerable number of settings. Perhaps a simple <requestHandler name="foo" extends="bar"...> syntax would do? Then we could get pretty one-liners if just one parameter changes from the parent.
          Hide
          David Smiley added a comment -

          I suspected you would be interested in this issue, Jan.

          Yes, it could be as simple as an extends attribute there. That was my initial idea. Two other questions:

          • Is there an implied default inherited request handler? Here you could specify "df", "q.op", "f.myfieldname.facet.method", ...
          • Could/should you be able to declare a handler that is only for extension and not for direct use? If so then how would it be declared as such?
          • multiple extended request handlers resulting in mixin capability? – e.g extends="base,foo,bar" Or is this overkill?

          There is something to be said for simplicity of how it works. So maybe simply one parent, no way to prevent a search of a RH aside from avoiding a leading '/' (assuming handleSelect is disabled) which is good enough... and maybe no default extends since all the RH definitions declared in solrconfig.xml out of the box could refer to a base one.

          This should be easy to implement.

          Show
          David Smiley added a comment - I suspected you would be interested in this issue, Jan. Yes, it could be as simple as an extends attribute there. That was my initial idea. Two other questions: Is there an implied default inherited request handler? Here you could specify "df", "q.op", "f.myfieldname.facet.method", ... Could/should you be able to declare a handler that is only for extension and not for direct use? If so then how would it be declared as such? multiple extended request handlers resulting in mixin capability? – e.g extends="base,foo,bar" Or is this overkill? There is something to be said for simplicity of how it works. So maybe simply one parent, no way to prevent a search of a RH aside from avoiding a leading '/' (assuming handleSelect is disabled) which is good enough... and maybe no default extends since all the RH definitions declared in solrconfig.xml out of the box could refer to a base one. This should be easy to implement.
          Hide
          Jan Høydahl added a comment -

          My thought was a super-simple approach. A RequestHandler with an extends would be initialized with a NamedList being the sum of the parent and the sub. For this to work, the parsing of <requestHandler> tags in solrconfig.xml would necessarily need to be done in correct order... Should we allow any number of levels or only one?

          Show
          Jan Høydahl added a comment - My thought was a super-simple approach. A RequestHandler with an extends would be initialized with a NamedList being the sum of the parent and the sub. For this to work, the parsing of <requestHandler> tags in solrconfig.xml would necessarily need to be done in correct order... Should we allow any number of levels or only one?
          Hide
          Hoss Man added a comment -

          SOLR-112?

          See also...

          http://www.lucidimagination.com/search/document/1590fe9ba73bc159#48acd4edb977be0d

          ...as you note in the
          latter comments, we ultimately we hit a wall in trying to determine a
          "generic" way to merge the init params for any arbitrary RequestHandler –
          things like default/invariant/appends are conventions of the OOTB
          handlers, but not all handlers are garunteed to support them.

          ...this is however something that could probably be added explicitly to SearchHandler in a fairly straight forward manner.

          Show
          Hoss Man added a comment - SOLR-112 ? See also... http://www.lucidimagination.com/search/document/1590fe9ba73bc159#48acd4edb977be0d ...as you note in the latter comments, we ultimately we hit a wall in trying to determine a "generic" way to merge the init params for any arbitrary RequestHandler – things like default/invariant/appends are conventions of the OOTB handlers, but not all handlers are garunteed to support them. ...this is however something that could probably be added explicitly to SearchHandler in a fairly straight forward manner.

            People

            • Assignee:
              Unassigned
              Reporter:
              David Smiley
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development