Hi, All
When I did AtomicUpdate on SolrCloud by the following setting, it does
not work properly.
---
---
When changed as follows and made it work, it became as expected.
---
---
The later setting and the way of using post-processor could make the
same result, I though,
but u
matthew,
In the future too, it's still going to be
"curl solr:8983/collection/dataimport?blah"
It's just that, you will have to run 2 or 3 extra commands for once
before you run that curl command
On Fri, Jul 17, 2020 at 3:50 PM Ishan Chattopadhyaya
wrote:
>
> For any further discussion on the de
Hi All
Sorry, above settings are contrary with each other.
Actually, following setting does not work properly.
---
---
And follows is working as expected.
---
---
Thanks,
Yoshiaki
2020年7月17日(金) 16:32 yo tomi :
> Hi, All
> When I did AtomicUpdate on SolrCloud by the follow
What does „not work correctly mean“?
Have you checked that all fields are stored or doc values?
> Am 17.07.2020 um 11:26 schrieb yo tomi :
>
> Hi All
>
> Sorry, above settings are contrary with each other.
> Actually, following setting does not work properly.
> ---
>
>
>
>
>
>
> ---
> An
There it is: https://issues.apache.org/jira/browse/SOLR-14662. I'd love to dig
deeper into that and provide a patch for it, but I'm fully occupied with our
own project.
Thanks and best regards,
Marc
-Ursprüngliche Nachricht-
Von: Erick Erickson
Gesendet: Donnerstag, 16. Juli 2020 15:06
Yes, I saw that yesterday.
I guess that I was not the only one who noticed the unreliability after all.
-Original Message-
From: Ishan Chattopadhyaya
Sent: Friday, July 17, 2020 1:17 AM
To: solr-user
Subject: Re: CDCR stress-test issues
FYI, CDCR support, as it exists in Solr today, h
Instead of CDCR you may simply duplicate the pipeline across both data centers.
Then there is no need at each step of the pipeline to replicate (storage to
storage, index to index etc.).
Instead both pipelines run in different data centers in parallel.
> Am 24.06.2020 um 15:46 schrieb Oakley, Cr
I have the same problem in my Solr8.
I think it's because in the first way,
TrimFieldUpdateProcessorFactory and RemoveBlankFieldUpdateProcessorFactory
is not taking effect.
On SolrCloud, TrimFieldUpdateProcessorFactory,
RemoveBlankFieldUpdateProcessorFactory and other processors
only run on the fi
Deprecation announces an intention to remove. One of the main reasons given
in the jira tickets I saw for deprecation sooner rather than later, is to
ensure discussions happen and replacements, migrations and I assume even
possibly decisions not to deprecate after all can be well sorted out and
the
