lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anshum Gupta (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-12502) Unify and reduce the number of SolrClient#add methods
Date Fri, 28 Sep 2018 00:41:00 GMT

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

Anshum Gupta commented on SOLR-12502:
-------------------------------------

My thoughts echo what [~tomasflobbe] thinks and I feel like we should not keep our APIs in
a flux, something that we have done in the past. I am not opposed to changes but if at all
we do that I would want to be sure that we 1. ensure back-compat and 2. make sure the path
we're trying to move on is a long term thing.

> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message