gerlowskija commented on code in PR #2177:
URL: https://github.com/apache/solr/pull/2177#discussion_r1442905887
##########
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##########
@@ -175,6 +175,19 @@ public void setQueryParams(Set<String> queryParams) {
public abstract SolrParams getParams();
+ /**
+ * Determines whether this request should use or ignore any specified data
stores (esp. {@link
+ * SolrClient#defaultCollection})
+ *
+ * <p>Many Solr requests target a particular data store (i.e. core or
collection). But not all of
+ * them - many Solr APIs (e.g. security or other admin APIs) are agnostic of
data stores entirely.
+ * This method gives these requests a way to opt out of using {@link
SolrClient#defaultCollection}
+ * or other specified data stores.
+ */
+ public boolean requiresDataStore() {
Review Comment:
Yeah, obviously "index" was my first instinct in the discussion on PR #1978,
where this initially came up. So I'm not totally against the idea.
The argument against it at the time, which ultimately swayed me, was that
because we're in a Lucene/IR context "index" is just too (over)loaded of a
term. "index" means something very specific to folks coming from Lucene, and
in Solr's own Lucene-adjacent code. I think a lot of people would be confused
if we started using "index" to refer to N different Lucene indices spread
across M machines.
Or as Eric put it:
> I think I like anything BUT "index" because I think that is an overloaded
term that has specific meaning the closer to disk you get.. A Collection is
NEVER a index.
----
That said - happy to go with the consensus here if others like "index"? All
the reasoning in the world isn't much good if folks find "index" intuitive and
workable in practice 🤷
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
