[
https://issues.apache.org/jira/browse/SOLR-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16628774#comment-16628774
]
Jason Gerlowski commented on SOLR-12502:
----------------------------------------
> Ehh; in common cases this adds complexity, I think. Simply adding one
> document means you now need to use SolrInputDocumentProvider
True. Though it's worth mentioning that the "common case" itself disobeys the
community advice to use document-batching, and the mere presence of a
single-doc-add method steers people into misusing SolrJ. It may be the common
case, and worth disincentivizing at the same time. I'm not arguing for that I
guess, just mentioning the point.
I like your suggestion of using UpdateRequest as this builder-like type, as
opposed to inventing some new abstraction. If I get a few minutes, I'll take a
stab at seeing how this looks in a larger snippet and upload it here as an
example for discussion.
Lastly, re: the collection. I've noticed a few bug JIRAs crop up recently
related to the ways collections can be specified in SolrJ. Specifically,
SOLR-12415 and SOLR-12803. Maybe those build a good argument for changing how
SolrClient handles collections, totally independent of the
too-many-similar-methods discussion here.
> 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]
