You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2016/01/11 05:03:40 UTC
[jira] [Comment Edited] (SOLR-8097) Implement a builder pattern for
constructing a Solrj client
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org