[
https://issues.apache.org/jira/browse/SOLR-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091375#comment-15091375
]
Shawn Heisey edited comment on SOLR-8097 at 1/11/16 4:03 AM:
-------------------------------------------------------------
Code written and compiled with a particular version of SolrJ should work
properly if the SolrJ jar is replaced with a newer minor version. This
compatibility is not expected if the jar is replaced with a newer major version.
The general goal is that the Solr Java API will not change in minor versions,
but this is not guaranteed. The later discussion related to back-compat talks
about some new annotations designed to make it more clear which APIs will be
static and which are expected to change. The SolrJ API will always be guarded
more closely against change than the rest of Solr, because it is the API that
is used most commonly in user code.
When public APIs *do* change in a minor version, the old API is generally
marked as deprecated, so that existing code will still compile and function
properly. The deprecated API is completely removed from the next major version
(trunk).
was (Author: elyograg):
Code written and compiled with a particular version of SolrJ should work
properly if the SolrJ jar is replaced with a newer minor version. This
compatibility is not expected if the jar is replaced with a newer major version.
The general goal is that the Solr Java API will not change in minor versions,
but this is not guaranteed. The later discussion related to back-compat talks
about some new annotations designed to make it more clear which APIs will be
static and which are expected to change. The SolrJ API will always be guarded
more closely against change than the rest of Solr, because it is the API that
is used most commonly in user code.
When public APIs *do* change in a minor version, the old API is generally
marked as deprecated, and the API is completely removed from the next major
version (trunk), so that existing code will still compile and function properly.
> 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: Trunk
> Reporter: Hrishikesh Gadre
> Priority: Minor
>
> 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]
