[
https://issues.apache.org/jira/browse/SOLR-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789925#action_12789925
]
Yonik Seeley commented on SOLR-1644:
------------------------------------
bq. definitely it looks verbose (ugly) . But the point is where do we stop?
Where it makes sense. There's no reason for an all or nothing approach.
There's no reason not to give some special treatment to some main components.
If one want's to better decompose some of the state for each handler, I guess
there could be objects that represented that too?
class ResponseBuilder {
QueryInfo queryInfo;
FacetInfo facetInfo;
}
But perhaps we should have gone with the same strategy as the
UpdateProcessorChain... an actual object is created for each component to keep
the state for the request.
bq. I believe the public API's should have no dependency on components .
Changing from a method or member to a hash lookup doesn't reduce a dependency
when it's needed.
> Provide a clean way to keep flags and helper objects in ResponseBuilder
> -----------------------------------------------------------------------
>
> Key: SOLR-1644
> URL: https://issues.apache.org/jira/browse/SOLR-1644
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: Shalin Shekhar Mangar
> Assignee: Shalin Shekhar Mangar
> Fix For: 1.5
>
> Attachments: SOLR-1644.patch
>
>
> Many components such as StatsComponent, FacetComponent etc keep flags and
> helper objects in ResponseBuilder. Having to modify the ResponseBuilder for
> such things is a very kludgy solution.
> Let us provide a clean way for components to keep arbitrary objects for the
> duration of a (distributed) search request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
