[
https://issues.apache.org/jira/browse/SOLR-17866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18015420#comment-18015420
]
Jason Gerlowski commented on SOLR-17866:
----------------------------------------
bq. Agreed – that is really my main concern is that the same request code
behaves differently with two differnet clients
Did a bit of digging here. The real differentiator is the "base URL" used in
each case. Almost all HttpSolrClient instances on branch_9x today use a "root
URL" (i.e. one ending in "/solr"). But CloudSolrClient is a notable exception
- it builds "core URL" strings and passes those to the HttpSolrClients it uses
internally.
So the "requiresCollection" and path-building logic operates consistently in
both cases - it sees that "requiresCollection==false" and avoids appending a
collection name to the base URL regardless of the client being used. But it
just so happens that the "baseURL" in the CloudSolrClient case already has the
core name on the URL, so the request succeeds.
Interestingly the discrepancy disappears on 'main', because the "remove core
URL" work was able to make modifications to CloudSolrClient that backcompat
wouldn't allow on branch_9x. It'd still be nice to fix the 9x inconsistency,
but I'd have to think some more about if/how that could be done since
backcompat requires that we still support "core URLs" appearing in
constructors, etc. on the 9x line.
bq. add a variant constructor to GenericSolrRequest that takes in a boolean
requiresCollection
I like this strawman, and it's very similar (identical?) to something
[~dsmiley] proposed [in an earlier PR
comment|https://github.com/apache/solr/pull/3423#issuecomment-3130084660]. (As
I referenced in my previous comment, he seemed to waver on it a bit later, so
I'm not sure if he's still on board or thought of some concerns). Absent any
forthcoming objections though, I'll aim to work on a PR for that approach
shortly.
> 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]
