Wait. What do you mean by: "... this deletion is not immediately
reflected in the search results..."? Like all other index operations
this change won't be "visible" until the next commit, but
expungeDeletes is (or should be) totally unnecessary. And very costly
for reasons other than you might be aware of, see:https://lucidworks.com/2017/10/13/segment-merging-deleted-documents-optimize-may-bad/
If you commit after docs are deleted and _still_ see them in search
results, that's a JIRA. That should simply _not_ be the case.
Do note, however, that DBQ can take quite a long time to run. Is it
possible that the delete isn't complete yet for some reason?
As for why there's not an "Update By Query", it's actually fairly
awful to deal with. Imagine in Solr's case what
UpdateByQuery, set fieldX=32, q=*:*. In order for that to work
1> It's possible that the update single-valued docValues fields (which
doesn't need all fields stored) could be made to work with that. That
functionality is so new, though, that it hasn't been addressed (and
I'm not totally sure it's possible).
Assuming the case isn't <1>, it would require
2> it's use "atomic updates under the covers, meaning:
2a> all fields be stored (a pre-requisite for Atomic Updates)
2b> each and every document would be completely re-indexed.
Inverted indexes don't lend themselves well to bulk updates....
On Fri, Jan 26, 2018 at 9:50 AM, Walter Underwood <[EMAIL PROTECTED]> wrote: