[
https://issues.apache.org/jira/browse/SOLR-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16629253#comment-16629253
]
Tomás Fernández Löbbe commented on SOLR-12502:
----------------------------------------------
Thanks for looking at this [~gerlowskija]. Reading all the comments, I’m a bit
on the fence really. Yes, the {{SolrClient}} interface has many overloaded
methods but on the other hand it’s very clear what they do and they are clearly
documented. I don’t think this is a source of confusion for our users and I
believe it helps the user keep a relatively clean code (like, if they have a
list of docs they can just call the {{add(list)}} and not need to implement any
interfaces for that). I don’t want to block improvements in this, but at the
same time, I want to make sure we think very well in the backward compatibility
implication of any change to these classes. Any changes here can essentially
break, not only all the users code but also any blogs/examples out the in the
wild, that may cause much more confusion for users than the fact that
SolrClient has many methods.
bq. using UpdateRequest as this builder-like type
I think this is a good idea, especially to prevent the proliferation of new
methods in SolrClient
bq. the mere presence of a single-doc-add method steers people into misusing
SolrJ
Right, but this is the first thing new users will see, I think we want to keep
it very simple to not scare them away. I think some javadocs (or better docs in
the Ref Guide) should be enough to guide people into batching.
> Unify and reduce the number of SolrClient#add methods
> -----------------------------------------------------
>
> Key: SOLR-12502
> URL: https://issues.apache.org/jira/browse/SOLR-12502
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
> Reporter: Varun Thacker
> Priority: Major
>
> On SOLR-11654 we noticed that SolrClient#add has 10 overloaded methods which
> can be very confusing to new users.
> Also the UpdateRequest class is public so that means if a user is looking for
> a custom combination they can always choose to do so by writing a couple of
> lines of code.
> For 8.0 which might not be very far away we can improve this situation
>
> Quoting David from SOLR-11654
> {quote}Any way I guess we'll leave SolrClient alone. Thanks for your input
> Varun. Yes it's a shame there are so many darned overloaded methods... I
> think it's a large part due to the optional "collection" parameter which like
> doubles the methods! I've been bitten several times writing SolrJ code that
> doesn't use the right overloaded version (forgot to specify collection). I
> think for 8.0, *either* all SolrClient methods without "collection" can be
> removed in favor of insisting you use the overloaded variant accepting a
> collection, *or* SolrClient itself could be locked down to one collection at
> the time you create it *or* have a CollectionSolrClient interface retrieved
> from a SolrClient.withCollection(collection) in which all the operations that
> require a SolrClient are on that interface and not SolrClient proper.
> Several ideas to consider.
> {quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
