[
https://issues.apache.org/jira/browse/SOLR-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16622549#comment-16622549
]
David Smiley commented on SOLR-12502:
-------------------------------------
Ehh; in common cases this adds complexity, I think. Simply adding one document
means you now need to use SolrInputDocumentProvider, which is also a new
abstraction.
Towards the end of your suggestion, in terms of "builder like", you have me
thinking we already have UpdateRequest which is to a degree builder like.
Perhaps it could be made to work with SolrClient even more easily. Ideally,
IMO, you could have some client code that only needs to import SolrClient in
scope to then call methods on SolrClient that perhaps work with UpdateRequest
and you finally submit it. Today this is invisible with add() which is
completely hiding it's use of UpdateRequest but imagine this:
{{solrClient.updateReq().add(myDoc).setCommitWithin(commitWithinMs).setCollection(collection).send()}}
RE the collection: We could make the notion of a default collection built-in to
each SolrClient. And if you want to change it then you wrap one with a
delegate SolrClient that changes settings like this. HttpSolrClient would have
to change a little to be more clear on wether it has a default collection or
not; it's a bit ambiguous today leaving it up to whoever writes the URL.
> 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]
