[
https://issues.apache.org/jira/browse/SOLR-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631779#comment-16631779
]
Jason Gerlowski commented on SOLR-12502:
----------------------------------------
bq. I don’t think this is a source of confusion for our users
Agreed. I don't think anyone's confused when their method type-ahead shows 10
{{add}} variants. They get it.
bq. I feel like we should not keep our APIs in a flux, something that we have
done in the past
Again, I agree. Your point about API churn, Anshum and Tomas, is well taken.
The bar is pretty high to make SolrClient changes worth the user
confusion/work. Purely cosmetic changes aren't worth it.
But there's more than cosmetic benefits to the brainstormed ideas above. There
are a lot of problems that are caused or exacerbated by the current SolrClient
interface. It makes it easy for users to do any number of behaviors that the
community warns against in the strongest terms: non-batch indexing,
client-invoked commits and rollbacks, etc. The support in the SolrClient
interface for multiple collections has also caused a lot of problems
historically (see my last comment above). And more cosmetically, the method
overloading is only partially effective: I regularly see client code that needs
to repackage a {{SolrInputDocument[]}} into a List to call {{add}}, for
example. These are all more or less related to the SolrClient interface's
method overloading or the fixes proposed.
Is the disruption of changing the interface worth it for the cosmetic
improvements? No. Is the disruption worth it if the change also eases some of
the nagging and painful problems SolrJ users run into? Maybe. The answer
could still very well be "no", but if we're weighing tradeoffs now, it's worth
pointing out the more concrete benefits.
> 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]
