[
https://issues.apache.org/jira/browse/SOLR-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-8097:
----------------------------------
Attachment: SOLR-8097.patch
bq. Let's carry on with adding tests, javadocs, deprecation, and also using
this in existing tests. We might not want to change all the tests but
optionally pick between builder and existing way of constructing the clients
for now in the tests though.
Time for a short check-in on making the revisions you suggested [~anshumg]:
- tests? check.
- javadocs? check.
- deprecation? nope.
- using in existing tests? In progress (see below).
The attached patch changes all tests that previously created {{HttpSolrClient}}
objects directly. With this patch, these tests now either use the builder, or
create the objects directly, based on the tests' {{random()}} value. Is that
about what you were thinking of when you suggested this Anshum?
Should this (or a similar change) be made to all test files that create
SolrClients, or just enough of the tests to get decent exposure for the
builder? I'd push for creating SolrClients uniformly in all the tests, though
that does make this patch/commit much more burdensome in many aspects (keeping
it up to date, reviewing it, etc.). So I see arguments either way. I'll
revise the changes in the HttpSolrClient-consuming tests, and make similar
changes for tests consuming the other types of SolrClients once I hear any
thoughts that others might have.
> Implement a builder pattern for constructing a Solrj client
> -----------------------------------------------------------
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Affects Versions: master
> Reporter: Hrishikesh Gadre
> Assignee: Anshum Gupta
> Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch,
> SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors
> as follows,
> public CloudSolrClient(String zkHost)
> public CloudSolrClient(String zkHost, HttpClient httpClient)
> public CloudSolrClient(Collection<String> zkHosts, String chroot)
> public CloudSolrClient(Collection<String> zkHosts, String chroot, HttpClient
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient
> httpClient)
> It is kind of problematic while introducing an additional parameters (since
> we need to introduce additional constructors). Instead it will be helpful to
> provide SolrClient Builder which can provide either default values or support
> overriding specific parameter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
