[
https://issues.apache.org/jira/browse/SOLR-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16728820#comment-16728820
]
Yosef Brown edited comment on SOLR-12502 at 12/25/18 10:03 PM:
---------------------------------------------------------------
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}}.
was (Author: yosef.brown):
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: [email protected]
For additional commands, e-mail: [email protected]
