[
https://issues.apache.org/jira/browse/SOLR-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482726#comment-16482726
]
Jason Gerlowski commented on SOLR-12309:
----------------------------------------
Hmm, it's an interesting idea. And I appreciate your humoring me in getting
back the compile-time guidance/errors. I guess I'm just stuck understanding
your underlying motivation for wanting to get the no-arg ctors back. I can see
few reasons that'd make sense, I'm just wondering which ones you're interested
in, and how this patch helps them.
Is your concern a slippery-slope explosion of ctors if SolrJ gains some more
required arguments in the future? Is your goal to make the Builder more
fluent, and you see eliminating ctor arguments as a step towards that? Or do
you think this is more intuitive from an end-user perspective than the
currently committed ctors/approach? Or is there some other motivation?
You patch does regain a no-arg ctor of sorts, but the next method call MUST be
to provide the zk-host/url-list- you can't call setters in whatever order you
please. IMO that undercuts any gains in "fluent"-ness and leaves things
looking oddly similar to the interface/ctors we have currently.
Maybe you prefer this approach because of it prevents a potential ctor
explosion if other SolrClient arguments become required. But I'm not sure
whether it prevents the explosion, or just shuffles the "bomb" around to other
types (tiny Builder implementations).
I guess at this point my vote is still to improve the Javadocs and other
documentation around this, rather than reworking the interface. But I'm happy
to be overruled or have my misconceptions corrected. I'll unassign myself in
case you want to pursue a non-documentation solution. I'll still work on
Javadocs independently- they'll be useful for devs in the interim even if we
end up changing the interface going forward.
> 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
> Assignee: Jason Gerlowski
> 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: [email protected]
For additional commands, e-mail: [email protected]
