[
https://issues.apache.org/jira/browse/SOLR-17866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18015191#comment-18015191
]
Jason Gerlowski edited comment on SOLR-17866 at 8/20/25 2:25 PM:
-----------------------------------------------------------------
bq. but I haven't convinced Jason
I kindof thought we'd found a compromise approach that we were both OK with
[here|https://github.com/apache/solr/pull/3423#issuecomment-3130084660]. But
maybe I misunderstood?
-Anyway, IMO the behavior Hoss describes above seems like a pretty clear bug,
regardless of any design or interface changes we might consider around
SolrRequest, etc. in the future. I'll take a look this week and see if I can't
understand what's going on.-
Actually, at the risk of saying something probably unpopular - I missed that
Hoss's code snippet above wasn't calling {{setRequiresCollection}} on these
requests that do require a collection/core.
The purpose of "GSR.setRequiresCollection", ultimately, is to tell the
URL-building code whether it should include any provided collection name
(either one specified as a client-level "default", or as a method parameter,
etc.) in the constructed URL path. We're not specifically telling GSR to
include the coll name in the path, so it builds the path without. So
unfortunately, in that sense I think the behavior of these single-node clients
is "correct".
The behavior-discrepancy between the cloud and single-node clients *does* seem
like a bug. So I'll look into that. And while the current behavior seems
"correct", IMO it's also clearly trappy. So I'll try to think through how we
might improve that and report back here shortly.
was (Author: gerlowskija):
bq. but I haven't convinced Jason
I kindof thought we'd found a compromise approach that we were both OK with
[here|https://github.com/apache/solr/pull/3423#issuecomment-3130084660]. But
maybe I misunderstood?
Anyway, IMO the behavior Hoss describes above seems like a pretty clear bug,
regardless of any design or interface changes we might consider around
SolrRequest, etc. in the future. I'll take a look this week and see if I can't
understand what's going on.
> GenericSolrRequest.process(client,collection) ignores collection with some
> client impls
> ---------------------------------------------------------------------------------------
>
> Key: SOLR-17866
> URL: https://issues.apache.org/jira/browse/SOLR-17866
> Project: Solr
> Issue Type: Bug
> Affects Versions: 9.7, 9.8, 9.9
> Reporter: Chris M. Hostetter
> Priority: Major
>
> If you use the {{public final T process(SolrClient client, String
> collection)}} method of a {{GenericSolrRequest}} the {{collection}} param
> seems to be ignored (by default) for "single node" {{SolrClient}} impls.
> The problem does not seem to apply when using a "Cloud" based {{SolrClient}}
> impl.
> This behavior did not exist up to and including 9.6.1
> ----
> A (possible) work around is to call
> {{GenericSolrRequest.setRequiresCollection(true)}} anytime you know you
> intend to pass a non-null {{collection}} argument to the {{process(...)}}
> method
> (I have only verified this work around in a very small number of cases)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
