Details

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

      Description

      Goals:

      • per field parameters that fall back to global values
      • defaults in solrconfig.xml per request handler, overridable per

      This is desirable for highlighting additions: http://issues.apache.org/jira/browse/SOLR-37

      last email thread: http://www.nabble.com/parameter-defaults-and-config-tf2020863.html#a5556298

      1. dismax-solrparams.patch
        14 kB
        Hoss Man
      2. solrparams.patch
        36 kB
      3. solrparams.patch
        19 kB
        Yonik Seeley

        Activity

        Hide
        Yonik Seeley added a comment -

        prototype implementation for feedback/discussion:

        • changed standard request handler, but not plugin utils it calls
        • untested for new functionallity, but all current tests pass
        Show
        Yonik Seeley added a comment - prototype implementation for feedback/discussion: changed standard request handler, but not plugin utils it calls untested for new functionallity, but all current tests pass
        Hide
        Yonik Seeley added a comment -

        Attached refresh.

        Unless someone thinks this is going off in the wrong direction, I'll commit this soon so others can work on it also.

        Show
        Yonik Seeley added a comment - Attached refresh. Unless someone thinks this is going off in the wrong direction, I'll commit this soon so others can work on it also.
        Hide
        Mike Klaas added a comment -

        Looks good! I especially like how trivial it is to create arbitrarily-nested parameter chains. One thing I believe that was lost in this patch is static (source-level) defaults for parameters. Presumably these would be defined using another level of defaul parameters which is a static member of CommonParams or somesuch?

        Also, should SolrParams.parseBool() perhaps do a case-insensitive test?

        Show
        Mike Klaas added a comment - Looks good! I especially like how trivial it is to create arbitrarily-nested parameter chains. One thing I believe that was lost in this patch is static (source-level) defaults for parameters. Presumably these would be defined using another level of defaul parameters which is a static member of CommonParams or somesuch? Also, should SolrParams.parseBool() perhaps do a case-insensitive test?
        Hide
        Yonik Seeley added a comment -

        Committed current version.

        Left to do off the top of my head:

        • deprecate methods dealing with params in PluginUtils
        • change use of deprecated methods (including dismax handler)
        • dismax handler: were to get defaults from solrconfig.xml... the base level, or "defaults". If the latter, provide some backward compat for existing configs?

        Highlighter stuff:

        • allow specification of markup
        • allow fragsize per-field
        • keep in mind recent highlighter work going on in Lucene... we should try and specify what instead of how (not use exact class names, etc)
        • start using "hl" namespace for highlighter params... this is just a convention to help clarify the semantics of a parameter at a glance.
        • for consistency, should "highlight" => "hl", "highlightFields" => "hl.fields" or "hl.fl", "maxSnippets" => "hl.snippets"?
          Normally backward compatibility is very important for the external interfaces, but things will change while a feature is in development... every commit does not constitute a release. Is highlighting new enough that we can change these parameters? Is anyone using these parameters in production where it would be a burden if we changed these?

        Examples of potential highlighter param names:
        hl=true
        hl.fl=name,title,body
        hl.snippets=4
        hl.fragsize=100
        hl.formatter=simple
        hl.simple.pre=<em>
        hl.simple.post=</em>

        And per field params:
        f.title.hl.fragsize=0 // overrides fragsize only for field 'title'

        Show
        Yonik Seeley added a comment - Committed current version. Left to do off the top of my head: deprecate methods dealing with params in PluginUtils change use of deprecated methods (including dismax handler) dismax handler: were to get defaults from solrconfig.xml... the base level, or "defaults". If the latter, provide some backward compat for existing configs? Highlighter stuff: allow specification of markup allow fragsize per-field keep in mind recent highlighter work going on in Lucene... we should try and specify what instead of how (not use exact class names, etc) start using "hl" namespace for highlighter params... this is just a convention to help clarify the semantics of a parameter at a glance. for consistency, should "highlight" => "hl", "highlightFields" => "hl.fields" or "hl.fl", "maxSnippets" => "hl.snippets"? Normally backward compatibility is very important for the external interfaces, but things will change while a feature is in development... every commit does not constitute a release. Is highlighting new enough that we can change these parameters? Is anyone using these parameters in production where it would be a burden if we changed these? Examples of potential highlighter param names: hl=true hl.fl=name,title,body hl.snippets=4 hl.fragsize=100 hl.formatter=simple hl.simple.pre=<em> hl.simple.post=</em> And per field params: f.title.hl.fragsize=0 // overrides fragsize only for field 'title'
        Hide
        Hoss Man added a comment -

        Overhaul of DisMax handler to use SolrParams, and deprecated all of the SolrPluginUtil.get*Param methods.

        Backwards compatible support was added to treat all init params as defaults if no init param named "defaults" was specified.

        If no one spots any problems with this patch I'd like to commit it tomorow (Wed).

        Show
        Hoss Man added a comment - Overhaul of DisMax handler to use SolrParams, and deprecated all of the SolrPluginUtil.get*Param methods. Backwards compatible support was added to treat all init params as defaults if no init param named "defaults" was specified. If no one spots any problems with this patch I'd like to commit it tomorow (Wed).
        Hide
        Mike Klaas added a comment -

        Looks fine after a cursory examination.

        Show
        Mike Klaas added a comment - Looks fine after a cursory examination.
        Hide
        Hoss Man added a comment -

        commited dismax-solrparams.patch

        Still todo: Completely remove refrences to deprecated methods (ie: req.getParam should be req.getParams().get) from within the core code base.

        Show
        Hoss Man added a comment - commited dismax-solrparams.patch Still todo: Completely remove refrences to deprecated methods (ie: req.getParam should be req.getParams().get) from within the core code base.
        Hide
        Yonik Seeley added a comment -

        closing... the removal of deprecated methods should probably be more tied to releases.

        Show
        Yonik Seeley added a comment - closing... the removal of deprecated methods should probably be more tied to releases.
        Hide
        Hoss Man added a comment -

        This bug was modified as part of a bulk update using the criteria...

        • Marked ("Resolved" or "Closed") and "Fixed"
        • Had no "Fix Version" versions
        • Was listed in the CHANGES.txt for 1.1

        The Fix Version for all 38 issues found was set to 1.1, email notification
        was suppressed to prevent excessive email.

        For a list of all the issues modified, search jira comments for this
        (hopefully) unique string: 20080415hossman3

        Show
        Hoss Man added a comment - This bug was modified as part of a bulk update using the criteria... Marked ("Resolved" or "Closed") and "Fixed" Had no "Fix Version" versions Was listed in the CHANGES.txt for 1.1 The Fix Version for all 38 issues found was set to 1.1, email notification was suppressed to prevent excessive email. For a list of all the issues modified, search jira comments for this (hopefully) unique string: 20080415hossman3

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development