Summary
When filtering resources using a null value (e.g. config.metadata.name=null), the intent is to match resources where the target field is either explicitly set to null or entirely absent from the stored document. On SQLite, only the first case is currently handled correctly — resources where the field is missing are silently excluded from results.
Motivation
The SQLite metastore backend relies on json_tree to navigate JSON documents when building filter clauses. Because json_tree only emits rows for fields that are present in the document, a missing field produces no row and is never matched. This means a user asking for resources with no name (or similar optional fields) will get incomplete results on SQLite with no indication that anything is wrong. The MySQL backend is not affected, as its JSON_CONTAINS semantics differ.
Scope
The fix should be confined to the SQLite-specific query building logic in the metastore layer — specifically the part responsible for translating a null filter candidate into a SQL fragment. The suggested approach is to use json_extract instead of json_tree for this case, since SQLite's json_extract returns SQL NULL for both a stored JSON null and a missing path, making it correct for both scenarios. Unit tests covering the null/absent-field filtering behaviour on SQLite should be added alongside the fix.
Summary
When filtering resources using a
nullvalue (e.g.config.metadata.name=null), the intent is to match resources where the target field is either explicitly set tonullor entirely absent from the stored document. On SQLite, only the first case is currently handled correctly — resources where the field is missing are silently excluded from results.Motivation
The SQLite metastore backend relies on
json_treeto navigate JSON documents when building filter clauses. Becausejson_treeonly emits rows for fields that are present in the document, a missing field produces no row and is never matched. This means a user asking for resources with no name (or similar optional fields) will get incomplete results on SQLite with no indication that anything is wrong. The MySQL backend is not affected, as itsJSON_CONTAINSsemantics differ.Scope
The fix should be confined to the SQLite-specific query building logic in the metastore layer — specifically the part responsible for translating a
nullfilter candidate into a SQL fragment. The suggested approach is to usejson_extractinstead ofjson_treefor this case, since SQLite'sjson_extractreturns SQLNULLfor both a stored JSONnulland a missing path, making it correct for both scenarios. Unit tests covering the null/absent-field filtering behaviour on SQLite should be added alongside the fix.