Clemens: Let's not raise a JIRA quite yet. I am 99% sure your test is not doing what you think or you have some invalid expectations. This is such a fundamental feature that it'd surprise me a _lot_ if it were a bug. Also, there are a bunch of DeleteByQuery tests in the junit tests that's run all the time..
Wait, are you issuing an explicit commit or not? I saw this phrase "...brutely by forcing a commit (with "expunge deletes")..." and saw the word "commit" and assumed you were issuing a commit, but re-reading that's not clear at all. Code should look something like update-via-delete-by-query solrClient.commit(); query to see if doc is gone. So here's what I'd try next: 1> Issue an explicit commit command (SolrCient.commit()) after the DBQ. The defaults there are openSearcher = true and waitSearcher= true. When that returns _then_ issue your query. 2> If that doesn't work, try (just for information gathering) waiting, several seconds after the commit to try your request. This should _not_ be necessary, but it'll give us a clue what's going on. 3> Show us the code if you can. Best, Erick On Sat, Jan 27, 2018 at 6:55 AM, Clemens Wyss DEV <clemens...@mysign.ch> wrote: > Erick said/wrote: >> If you commit after docs are deleted and _still_ see them in search results, >> that's a JIRA > should I JIRA it? > > -----Ursprüngliche Nachricht----- > Von: Shawn Heisey [mailto:apa...@elyograg.org] > Gesendet: Samstag, 27. Januar 2018 12:05 > An: solr-user@lucene.apache.org > Betreff: Re: AW: AW: SolrClient#updateByQuery? > > On 1/27/2018 12:49 AM, Clemens Wyss DEV wrote: >> Thanks for all these (main contributor's 😉) valuable inputs! >> >> First thing I did was getting getting rid of "expungeDeletes". My >> "single-deletion" unittest failed unti I added the optimize-param >>> updateReques.setParam( "optimize", "true" ); >> Does this make sense or should JIRA it? >> How expensive ist this "optimization"? > > An optimize operation is a complete rewrite of the entire index to one > segment. It will typically double the size of the index. The rewritten > index will not have any documents that were deleted in it. It's slow and > extremely expensive. If the index is one gigabyte, expect an optimize to > take at least half an hour, possibly longer, to complete. > The CPU and disk I/O are going to take a beating while the optimize is > occurring. > > Thanks, > Shawn
