[
https://issues.apache.org/jira/browse/SOLR-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551015#comment-16551015
]
Jason Gerlowski commented on SOLR-12502:
----------------------------------------
The {{add}} methods are especially egregious, but it's worth pointing out that
the problem is endemic to most of the bunches of {{SolrClient}} methods. As of
7.4, we have:
- 10 {{add}} methods (5 w/ collection, 5 w/o)
- 4 {{addBean}} methods (2 w/ collection, 2 w/o)
- 6 {{addBeans}} methods (3 w/ collection, 3 w/o)
- 6 {{commit}} methods (3 w/ collection, 3 w/o)
- 8 {{deleteById}} methods (4 w/ collection, 4 w/o)
- 4 {{deleteByQuery}} methods (2 w/ collection, 2 w/o)
- 8 {{getById}} methods (4 w/ collection, 4 w/o)
- 6 {optimize}} methods (3 w/ collection, 3 w/o)
- 4 {{query}} methods (2 w/ collection, 2 w/o)
Any solution we decide on for 8.0 would ideally also be applied to those other
method-groups as well. That's more work unfortunately, but it'd keep the API
coherent, which is probably best for our users.
Of the options David suggested back on SOLR-11654, I don't have any strong
opinions. I like the idea of Option 2 (locking SolrClient to a collection at
creation time)...it would clean up the interface, and we could remove some
complexity internal to SolrClient impl's as well. But I don't have a good feel
for how common it is today for users to reuse a single client across
collections. Forcing users to go from 1 to numCollections clients could be
expensive for CloudSolrClient too, with it connecting to ZK. Maybe others with
more experience could chime in on that? If those are issues, option (1) or (3)
is probably best.
> 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]
