(fix) Search Not operator

[ronso0]

Fixes #15918

The issue

was apparently that NULL values in any of the search columns cause trouble with the true/false/NULL logic in SQL.
I only know little about SQL and just learned about that ^, so after starring at SQL debug for some hours, scratching my head, and before going to sleep and digest -- here's my attempt to explain the issue (feel free to correct me):

When doing an untagged search like xxxy, all text columns are searched (artist, title, genre, grouping, comment, ..)

Relevant part of an untagged text query is
WHERE ((artist LIKE '%xxxy%') OR (album LIKE '%xxxy%') OR ..)
-> the outer WHERE keeps rows where ((.. LIKE ..) OR ..) is true (NULL and false are removed)
-> mismatches and NULL are removed

The NOT text query (-xxxy) would be
WHERE NOT ((artist LIKE '%xxxy%') OR (album LIKE '%xxxy%'))
-> the WHERE NOT keeps only rows that are false (-> NULL is not false <-)
-> matches and NULL are removed
-> less results than expected

and apparently many of my tracks had NULL in one of these columns, so these tracks were also not shown.

Fix

is also checking for IS NOT NULL in the TextFilterNode:
[column] IS NOT NULL AND [column] LIKE '%[searchterm]%'

Note: for testing you can cherry-pick 81741b7 from #14552 (main) to get the track count on the Tracks item label

[ronso0]

Tests fail because they expect the literal SQL strings xx LIKE '%searchterm%'
will fixup

[ronso0]

Hmm, I missed some occurences in the parser tests, but why do they succeed on macOS 15??

[ronso0]

Alrigthy, I managed to updat all parser tests (my regex had some flaws and I was to lazy to manually check all tests ; )
Ready for review!

[acolombier]

LGTM. Tested and the change fixes the issue. Thank you!

[ronso0]

Thanks for your quick review!

[ronso0]

And now I know why I always got so little results when searching for tech deep -work 😆 🚀

(interesting that I fully trusted the Mixxx query parser and only started investigating it after that report in the forums)