You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Yosef Brown (JIRA)" <ji...@apache.org> on 2018/12/25 22:03:00 UTC
[jira] [Commented] (SOLR-12502) Unify and reduce the number of
SolrClient#add methods
[ https://issues.apache.org/jira/browse/SOLR-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16728820#comment-16728820 ]
Yosef Brown commented on SOLR-12502:
------------------------------------
As long as we're taking the opportunity to revamp the {{add}} convenience methods, I would like to see them expose {{SolrParam}}s. I am using a {{DocBasedVersionConstraintsProcessorFactory}} with {{ignoreOldUpdates = true}}, but I wanted to know which documents in my batch were updated and which were (silently) rejected. The only way I found to do so was by adding the request parameter {{version=true}}, but that required me to abandon the convenient {{SolrClient#addBeans}} and use the {{DocumentObjectBinder#toSolrInputDocument}} directly with an {{UpdateRequest}} and {{ModifiableSolrParams}}.
> 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