[ 
https://issues.apache.org/jira/browse/SOLR-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482814#comment-16482814
 ] 

Shawn Heisey edited comment on SOLR-12309 at 5/21/18 5:55 PM:
--------------------------------------------------------------

This issue started out as confusion over how Optional worked, and desiring 
better javadoc.  And maybe that's where it should stay.  Design shifts can 
happen in another issue.

On the design:  I think the mix of constructors and fluent methods confuses the 
situation and gives an impression that we're undecided about whether we want 
fluent or not.

Here's another idea, sort of a meld of both approaches, abandoning the use of 
constructors, and a lot less complicated than what I last proposed.  Implement 
these static methods, as the only non-deprecated ways of obtaining a Builder 
object:

CloudSolrClient.builder(Collection<String> zkHosts, String chroot)
CloudSolrClient.builder(Collection<String> solrUrls)

If there's no chroot, that argument can be null, which most Java developers 
understand fully.  There may still be situations where using certain fluent 
methods might throw Illegal* exceptions, but there wouldn't be very many 
situations like that.

I think the other SolrClient implementations can get by with a single no-arg 
builder() method.



was (Author: elyograg):
This issue started out as confusion over how Optional worked, and desiring 
better javadoc.  And maybe that's where it should stay.  Design shifts can 
happen in another issue.

On the design:  I think the mix of constructors and fluent methods confuses the 
situation and gives an impression that we're undecided about whether we want 
fluent or not.

Here's another idea, sort of a meld of both approaches, abandoning the use of 
constructors, and a lot less complicated than what I last proposed.  Implement 
these static methods:

CloudSolrClient.builder(Collection<String> zkHosts, String chroot)
CloudSolrClient.builder(Collection<String> solrUrls)

If there's no chroot, that argument can be null, which most Java developers 
understand fully.  There may still be situations where using certain fluent 
methods might throw Illegal* exceptions, but there wouldn't be very many 
situations like that.

I think the other SolrClient implementations can get by with a single no-arg 
builder() method.


> CloudSolrClient.Builder constructors are not well documented
> ------------------------------------------------------------
>
>                 Key: SOLR-12309
>                 URL: https://issues.apache.org/jira/browse/SOLR-12309
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: clients - java
>    Affects Versions: 7.3
>            Reporter: Shawn Heisey
>            Priority: Minor
>         Attachments: fluent-builder-fail-compile-time.patch
>
>
> I was having a lot of trouble figuring out how to create a CloudSolrClient 
> object without using deprecated code.
> The no-arg constructor on the Builder object is deprecated, and the two 
> remaining methods have similar signatures to each other.  It is not at all 
> obvious how to successfully call the one that uses ZooKeeper to connect.  The 
> javadoc is silent on the issue.  I did finally figure it out with a lot of 
> googling, and I would like to save others the hassle.
> I believe that this is what the javadoc for the third ctor should say:
> ----
> Provide a series of ZooKeeper hosts which will be used when configuring 
> CloudSolrClient instances.  Optionally, include a chroot to be used when 
> accessing the ZooKeeper database.
> Here are a couple of examples.  The first one has no chroot, the second one 
> does:
> new CloudSolrClient.Builder(zkHosts, Optional.empty())
> new CloudSolrClient.Builder(zkHosts, Optional.of("/solr"))
> ----
> The javadoc for the URL-based method should probably say something to 
> indicate that it is easy to confuse with the ZK-based method.
> I have not yet looked at the current reference guide to see if that has any 
> clarification.
> Is it a good idea to completely eliminate the ability to create a cloud 
> client using a single string that matches the zkHost value used when starting 
> Solr in cloud mode?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to