Solr
  1. Solr
  2. SOLR-660

Simplify UpdateRequestProcessor API

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.3
    • Component/s: update
    • Labels:
      None

      Description

      SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration is too complicated and should be simplified before release 1.3

        Issue Links

          Activity

          Ryan McKinley created issue -
          Hide
          Ryan McKinley added a comment - - edited

          patch that removes the no-op factory and forces eveything to be a chain. Now the configuration looks like this:

          <updateRequestProcessorChain name="name" default="true">
            <processor class="solr.CustomUpdateRequestProcessorFactory" >
             <lst name="name">
               <str name="n1">x1</str>
               <str name="n2">x2</str>
             </lst>
            </processor>
            <processor class="solr.RunUpdateProcessorFactory" />
            <processor class="solr.LogUpdateProcessorFactory" />
          </updateRequestProcessorChain>
          

          The big changes are:

          • processor factories are now loaded with NamedListInitalizedPluginLoader – it is no longer custon Node parsing.
          • the Factories no longer have direct access to core. if they need it, they can implement SorlCoreAware
          • moves all config parsing out of the processor classes.
          Show
          Ryan McKinley added a comment - - edited patch that removes the no-op factory and forces eveything to be a chain. Now the configuration looks like this: <updateRequestProcessorChain name= "name" default= "true" > <processor class= "solr.CustomUpdateRequestProcessorFactory" > <lst name= "name" > <str name= "n1" > x1 </str> <str name= "n2" > x2 </str> </lst> </processor> <processor class= "solr.RunUpdateProcessorFactory" /> <processor class= "solr.LogUpdateProcessorFactory" /> </updateRequestProcessorChain> The big changes are: processor factories are now loaded with NamedListInitalizedPluginLoader – it is no longer custon Node parsing. the Factories no longer have direct access to core. if they need it, they can implement SorlCoreAware moves all config parsing out of the processor classes.
          Ryan McKinley made changes -
          Field Original Value New Value
          Attachment SOLR-660-update-processor.patch [ 12386913 ]
          Ryan McKinley made changes -
          Link This issue relates to SOLR-269 [ SOLR-269 ]
          Shalin Shekhar Mangar made changes -
          Summary Simlify UpdateRequestProcessor API Simplify UpdateRequestProcessor API
          Hide
          Shalin Shekhar Mangar added a comment -

          Thanks for opening this issue Ryan!

          The configuration looks much better and going with the NamedListInitializedPlugin and SolrCoreAware makes it more consistent with the RequestHandler and SearchComponent code base. Let me see how I can help

          Show
          Shalin Shekhar Mangar added a comment - Thanks for opening this issue Ryan! The configuration looks much better and going with the NamedListInitializedPlugin and SolrCoreAware makes it more consistent with the RequestHandler and SearchComponent code base. Let me see how I can help
          Hide
          Ryan McKinley added a comment -

          just committed this and updated the text on:
          http://wiki.apache.org/solr/UpdateRequestProcessor

          Shalin, if you could add more documentation / comments from your experience using it, that would be great.

          Show
          Ryan McKinley added a comment - just committed this and updated the text on: http://wiki.apache.org/solr/UpdateRequestProcessor Shalin, if you could add more documentation / comments from your experience using it, that would be great.
          Ryan McKinley made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Hide
          Noble Paul added a comment - - edited

          This looks very good, Ryan .The configuration is obvious as what it is doing though I'm still not convinced of the need for a factory (Eitherway it does not matter). I guess it would be nice to make the UpdateRequestProcessorFactory implements SolrCoreAware. Any initialization with the core can be done here.
          I have changed the wiki too

          Show
          Noble Paul added a comment - - edited This looks very good, Ryan .The configuration is obvious as what it is doing though I'm still not convinced of the need for a factory (Eitherway it does not matter). I guess it would be nice to make the UpdateRequestProcessorFactory implements SolrCoreAware. Any initialization with the core can be done here. I have changed the wiki too
          Hide
          Ryan McKinley added a comment -

          I guess it would be nice to make the UpdateRequestProcessorFactory

          any UpdateRequestProcessorFactory that needs access to SolrCore just needs to implement SolrCoreAware, then it will be initialized via the standard plugin stuff. Our base UpdateRequestProcessorFactory should not need SolrCore.

          It does not need to be a factory, but the chaining and state implementations (for non-trivial processors) is much more straight forward.

          Show
          Ryan McKinley added a comment - I guess it would be nice to make the UpdateRequestProcessorFactory any UpdateRequestProcessorFactory that needs access to SolrCore just needs to implement SolrCoreAware, then it will be initialized via the standard plugin stuff. Our base UpdateRequestProcessorFactory should not need SolrCore. It does not need to be a factory, but the chaining and state implementations (for non-trivial processors) is much more straight forward.
          Hide
          Noble Paul added a comment - - edited

          I noticed one more inconsistency. Factories are provided to control the creation of instances by the API consumers. In this design you almost force the implementers to create a new instance if the user needs to access the solrQueryRequest, solrQueryResponse parameters. As a design, constructing the UpdateRequestProcessor instance should not need these objects. By making available a runtime objects in the construction time only , the API disallow the user from having a singleton. The optimal design is to move all the runtime objects to method arguments

          Show
          Noble Paul added a comment - - edited I noticed one more inconsistency. Factories are provided to control the creation of instances by the API consumers. In this design you almost force the implementers to create a new instance if the user needs to access the solrQueryRequest, solrQueryResponse parameters. As a design, constructing the UpdateRequestProcessor instance should not need these objects. By making available a runtime objects in the construction time only , the API disallow the user from having a singleton. The optimal design is to move all the runtime objects to method arguments
          Uwe Schindler made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Ryan McKinley
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development