[
https://issues.apache.org/jira/browse/SOLR-17866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18015218#comment-18015218
]
Chris M. Hostetter commented on SOLR-17866:
-------------------------------------------
{quote}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.
{quote}
Correct – because it _predates_ the existence of {{setRequiresCollection}} ...
that's why it uses the two arg version of {{process(client,collectionName)}} --
because that usage pattern/recommendation for how to specify a collection name
predates the idea that a SolrCllient would ever have a "default collection"
configured on it
bq. So unfortunately, in that sense I think the behavior of these single-node
clients is "correct".
I don't know if i disagree with you -- i think that as the APIs evolve, it's
fine for us to say "you need to call {{setRequiresCollection}} in this type of
situation", it's just unfortunate that this type of change can "silently"
suprise users when upgrading.
bq. The behavior-discrepancy between the cloud and single-node clients does
seem like a bug.
Agreed -- that is really my main concern is that the same request code behaves
differently with two differnet clients
bq. IMO it's also clearly trappy. So I'll try to think through how we might
improve that and report back here shortly.
strawman:
1. add a variant constructor to {{GenericSolrRequest}} that takes in a
{{boolean requiresCollection}}, deprecated the other constructors (and the
{{setRequiresCollection}}) method in 9.10, remove the deprecations in 10. So
from now on ever {{GenericSolrRequest}} must be very explicit from the begining
about whether it is collection specific
2. Add some code to {{SolrRequest.process(client, collection)}} that looks
something like...
{code}
if (this.getRequiersCollection() && null == collection) { throw new
IllegalArgumentException }
{code}
...or maybe even...
{code}
if (this.getRequiersCollection() != (null == collection)) { throw new
IllegalArgumentException }
{code}
> 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]
