That would normally be done if you want to get those params before you have
parsed the form data. At some point, there were cases of that. And it’s
likely done with an attempt to be generic and work with whatever format
since it’s essentially a feature in user code. If the current use doesn’t
need
The
method
org.apache.solr.client.solrj.impl.HttpSolrClientBuilderBase#withTheseParamNamesInTheUrl
is only used by UpdateShardHandler so that "distrib.from" and
"update.distrib" (used by DistributedUpdateProcessor) are guaranteed to be
in the URL. It appears Dat added this during the http2 branch
While I like BATs test a lot.. maybe too much, I wonder if we could have a
single Java based test that hits all the V2 APIs and verifies them? Versus a
whole ton of curl commands in the bats style?
Is there some way to programmatically look up each v2 API and then issue a
request?
For som
Awesome, thanks Colvin!
I'll offer my 2c to your question about BATS vs Java tests on the PR,
per David's request that we not cross conversations here.
On Fri, Jan 10, 2025 at 1:05 PM Colvin Cowie wrote:
>
> I had a manual look through the *org.apache.solr.handler.admin.api*
> package, and I fou
I had a manual look through the *org.apache.solr.handler.admin.api*
package, and I found that *InstallCoreData* was also missing the @Inject,
everything else* looked* okay.
https://github.com/apache/solr/pull/3023 - I'm still to add the regression
tests (the checks are failing for reasons that appe
Hey all,
SolrJ's SolrClient implementations have an interesting bit of logic
around how they handle SolrParams.
In short: params are attached tothe request differently based on a
quite detailed series of checks. "GET" requests attach params to the
URL as traditional "query parameters". "POST an
It's been a while since I don't check that, @jason do you mean that:
1) results grouping happens after shard aggregations
2) field collapsing happens before shard aggregations
Literally shooting in the dark, just reading the email, with zero time to
investigate, but in general, I'm in favour of de
Hi,
Sorry for the late reply on this thread. I've been trying to take
time to understand the problem a little better before chiming in.
(FWIW I think this would be a great discussion for the Meetup next
week?)
I think much of what you described makes sense in a v1 context, but v2
has some nice b
I'm not against deprecating "Result Grouping" per-se, but it has one
huge advantage over Collapse/Expand: Result Grouping is the only
approach that supports multi-shard.
Should we come up with a plan for that and other gaps before we
deprecate Result Grouping? Deprecating the feature before there
+1 I'm not actively working on anything, but pinged #674 to see if it can be
landed.
Jan
> 9. jan. 2025 kl. 18:13 skrev Jason Gerlowski :
>
> Hey all,
>
> The operator has accumulated a nice few bug-fixes and improvements
> since our 0.8.1 release back in the Spring. What do we think about
>
10 matches
Mail list logo
