[
https://issues.apache.org/jira/browse/SOLR-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16619637#comment-16619637
]
Jason Gerlowski commented on SOLR-12502:
----------------------------------------
I've been mulling this over a bit recently, and I wanted to throw a few other
options out there and see what people think. Particularly, I think we can make
a big improvement here without needing to change how the the current
"collection" semantics. I'm gonna use {{add}} as an example. SolrClient has
10 ( ! ) different add methods. The variety comes from the (1) the collection
parameter, (2) the different ways to specify the document(s) themselves, and
(3) a commitWithin parameter. We could cut this in half by unifying the way
that the documents themselves are provided. Rather than accepting individual
SolrInputDocument instances, Collection<SolrInputDocument>,
Iterable<SolrInputDocument>, we could accept some wrapper type which has
trivial methods to convert whatever underlying bag of documents the user has.
I'm imagining a "SolrInputDocumentProvider" class with the methods below:
{code:java}
class SolrInputDocumentProvider extends Iterator<SolrInputDocument> {
public static SolrInputDocumentProvider
fromSingleDocument(SolrInputDocument doc);
public static SolrInputDocumentProvider fromDocuments(SolrInputDocument...
docs);
public static SolrInputDocumentProvider
fromDocuments(Collection<SolrInputDocument> docs);
public static SolrInputDocumentProvider fromDocuments(SolrInputDocument[]
docs);
public boolean hasNext();
public SolrInputDocument next();
}{code}
Users could then use the Iterator version of the add method with their raw
iterator, or could pass in SolrInputDocumentProvider to handle any other ways
they have their docs gathered. You could take this idea further and make the
"document-wrapper" class more builder-like by adding commitWithinMillis(long)
and toCollection(String) methods. That would let us trim SolrClient down to a
single {{add}} method without removing any functionality/capabilities that our
users might be using.
> 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]
