You’re welcome.
Solr is a huge beast, I don’t think any single individual
knows all the bits and pieces… Or, in my case, can
remember them ;)
> On Apr 27, 2020, at 9:15 AM, Bjarke Buur Mortensen
> wrote:
>
> Wow, thanks. Erick. That's actually much better :-)
> You live and you learn.
>
>
Wow, thanks. Erick. That's actually much better :-)
You live and you learn.
Cheers,
Bjarke
Den man. 27. apr. 2020 kl. 15.00 skrev Erick Erickson <
erickerick...@gmail.com>:
> What about the Collections API REINDEXCOLLECTION? That has the
> advantage of being something officially supported, puts
What about the Collections API REINDEXCOLLECTION? That has the
advantage of being something officially supported, puts the source
collection into read-only mode, uses a much more efficient query
process (streaming actually) etc.
It has the disadvantage of producing a new collection under the
Thanks for the reply,
I'm on solr 8.2 so cursorMark is there.
Doing this from one collection to another collection, and then use a
collection alias is probably the way to go, but actually, my suggestion
was a little more bold:
I'm indexing on top of the same core, i.e from
Hi Bjarke,
I don’t see a problem with that approach if you have enough resources to handle
both cores at the same time, especially if you are doing that while serving
production queries. The only issue is that if you plan to do that then you have
to have all fields stored. Also note that
Hi list,
Let's say I add a copyField to my solr schema, or change the analysis chain
of a field or some other change.
It seems to me to be an alluring choice to use a very simple
dataimporthandler to reindex all documents, by using a SolrEntityProcessor
that points to itself. I have just done
