Alright; thanks for your thorough response. If you/someone notices a
failure and we need to touch this again, let's follow up with a PR.
And I suspect we'll want to factor out the cleanup so more tests might
use this without the copy-pasted hack. Perhaps HttpJdkSolrClient
could do this cleanup
Shawn; SolrCloud only works with "id".
On Fri, Mar 15, 2024 at 4:29 PM Shawn Heisey
wrote:
>
> On 2/12/24 16:21, David Smiley wrote:
> > Just presume the uniqueKeyField to be "id", especially in SolrCloud.
> > If one of your users uses something different, I'd be surprised!
>
> My first install
On 2/12/24 16:21, David Smiley wrote:
Just presume the uniqueKeyField to be "id", especially in SolrCloud.
If one of your users uses something different, I'd be surprised!
My first install of Solr, which was version 1.4.0 (LONG before
SolrCloud), did NOT use "id" as the uniqueKey field name.
David, let me try and address your concerns with the approach. I am
open to other approaches, however, we need something that will work
consistently. I would like for what I have now to run in our CI for
at least a week to see if we get more failures or not, before changing
it further. I do
I wanted to follow up and share that I was able to get the compression logic to
all work.
See
https://github.com/apache/solr/pull/2298/commits/ee8657438799c07baadd8efa0f272bb57380d772
I *believe* that we could make the compression logic a option on
SolrZkClient.Builder(), maybe