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.... FWIW, Erick On Fri, Jan 26, 2018 at 9:50 AM, Walter Underwood <wun...@wunderwood.org> wrote: > Use a filter query to filter out all the documents marked deleted. > > Don’t use “expunge deletes”, it does more than you want because it forces a > merge. Just commit after sending the delete. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > > >> On Jan 26, 2018, at 8:55 AM, Clemens Wyss DEV <clemens...@mysign.ch> wrote: >> >> Thx Emir! >> >>> You are thinking too RDMS >> maybe the DBQ "missled" me 😉 >> >>> The best you can do is select and send updates as a single bulk >> how can I do "In-Place Updates" >> (https://lucene.apache.org/solr/guide/6_6/updating-parts-of-documents.html#UpdatingPartsofDocuments-In-PlaceUpdates) >> from/through SolrJ? >> >>> Also use DBQ with caution - it does not work well with concurrent updates >> we "prevent" this through sequentialization (per core ) >> >> Why do I want to do all this (dumb things)? The context is as follows: >> when a document is deleted in an index/core this deletion is not immediately >> reflected in the searchresults. Deletions at not really NRT (or has this >> changed?). Till now we "solved" this brutely by forcing a commit (with >> "expunge deletes"), till we noticed that this results in quite a "heavy >> load", to say the least. >> Now I have the idea to add a "deleted"-flag to all the documents that is >> filtered on on all queries. >> When it comes to deletions, I would upate the document's deleted flag and >> then effectively delete it. For single deletion this is ok, but what if I >> need to re-index? >> >> -----Ursprüngliche Nachricht----- >> Von: Emir Arnautović [mailto:emir.arnauto...@sematext.com] >> Gesendet: Freitag, 26. Januar 2018 17:31 >> An: solr-user@lucene.apache.org >> Betreff: Re: SolrClient#updateByQuery? >> >> Hi Clemens, >> You are thinking too RDMS. You can use query to select doc, but how would >> you provide what are updated doc? I guess you could use this approach only >> for incremental updates or with some scripting language. That is not >> supported at the moment. The best you can do is select and send updates as a >> single bulk. >> >> Also use DBQ with caution - it does not work well with concurrent updates. >> >> HTH, >> Emir >> -- >> Monitoring - Log Management - Alerting - Anomaly Detection Solr & >> Elasticsearch Consulting Support Training - http://sematext.com/ >> >> >> >>> On 26 Jan 2018, at 17:10, Clemens Wyss DEV <clemens...@mysign.ch> wrote: >>> >>> SolrClient has the method(s) deleteByQuery (which I make use of when I need >>> to reindex). >>> #updateByQuery does nicht exist. What if I want to "update all documents >>> matching a query"? >>> >>> >>> Thx >>> Clemens >> >
