[
https://issues.apache.org/jira/browse/SOLR-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617235#action_12617235
]
noble.paul edited comment on SOLR-660 at 7/26/08 8:52 PM:
----------------------------------------------------------
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
was (Author: noble.paul):
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 object in the construction time only , the API disallow the
user from having a singleton
> Simplify UpdateRequestProcessor API
> -----------------------------------
>
> Key: SOLR-660
> URL: https://issues.apache.org/jira/browse/SOLR-660
> Project: Solr
> Issue Type: Improvement
> Components: update
> Affects Versions: 1.3
> Reporter: Ryan McKinley
> Fix For: 1.3
>
> Attachments: SOLR-660-update-processor.patch
>
>
> SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration
> is too complicated and should be simplified before release 1.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
