Allow == and != against empty string

[mgaffigan]

Closes #300

Example channel for testing
search for empty string.xml

Test matrix:

1. Searching for == '' works on message with matching empty metadata
2. Searching for != '' works on message with matching populated metadata
3. Searching for == '' does not match on message with populated metadata
4. Searching for != '' does not match on message with empty metadata
5. Other filter operators continue being ignored if the value is ''

Not supported on Oracle.

[github-actions]

Test Results

666 tests  +3   666 ✅ +3   2m 24s ⏱️ + 1m 7s
112 suites +1     0 💤 ±0 
112 files   +1     0 ❌ ±0 

Results for commit 2b2d4fe. ± Comparison against base commit 762e072.

[pacmano1]

Is "metadata explicitly set to empty string" the intended scope? Blank == won't match messages where the variable was never set — those are NULL in D_MCM (or no row at all if the message had no metadata), and the admin tool renders all three states identically as blank. Having dug in, ''-only looks like the only clean semantics short of restructuring the search, so maybe just worth a line in the PR body.

Oracle is the real problem: verified against Oracle 23 Free with ojdbc8 that setString("") into the VARCHAR2(255 CHAR) metadata column stores NULL, and a bound '' matches zero rows with both = and !=. So on Oracle blank == can never match, and blank != goes from "row ignored" to "always zero results". Suggest an IS NULL/IS NOT NULL special case in oracle-message.xml, or an explicit "not supported on Oracle" note.

[mgaffigan]

@pacmano1, the intent is indeed "empty string". I agree that a future "not set" filter may be valuable (especially on oracle, which weirdly considers '' is null to be true).

[kryskool]

Hi @mgaffigan

Why not use a new "null or empty" checkbox instead of leaving the value field blank, which can be ambiguous?
this would make it easier to handle the issue raised by @pacmano1

Regards,

[mgaffigan]

Why not use a new "null or empty" checkbox instead of leaving the value field blank, which can be ambiguous?

Because equals empty was already supported by the backend, it only required the client to allow it.

I agree that future work to compare null would be useful.