Returning null/empty values in Lists / FQM
As of the Sunflower release, null/empty values in FQM are not handled in a consistent way. Users have reported this behavior as confusing and unexpected. It’s generally reported that the null / empty operator is working as expected. However, not including null/empty values in negative query conditions (e.g. field 1 is not equal to ‘test’), doesn’t match user expectations.
Proposal: in the Trillium release, update the default behavior for ‘not equal to’ and ‘not in’ operators to return null/empty values (rows 1 & 2 in the table below).
*Existing behavior = Poppy - Sunflower release; **Desired behavior = Trillium forward
Operator | Datatype | Sunflower release | Trillium release | |
|---|---|---|---|---|
| 1 | not equal to [value] |
| empty strings are returned, but null values are not | records with null / empty values are returned e.g., “User – Created date” not equal to “11/11/2025” returns records with null/empty values |
| 2 |
| N/A | records with null / empty values are returned e.g., “Instance – Language” not equal to “English” returns records with null/empty values | |
| 3 |
| empty strings are returned, but null values are not when value is set to “true” | records with null / empty values are returned when value is set to “true” e.g., “User – Active” not equal to “true” returns records with null/empty values | |
| 4 | empty strings are returned, but null values are not when value is set to “false” | records with null / empty values are returned when value is set to “false” e.g., “User – Active” not equal to “false” returns records with null/empty values | ||
| 5 | not in [value] |
| empty strings are returned, but null values are not *if the query includes an invalid UUID, null values are returned | records with null / empty values are returned e.g., “Patron group – Name” not in “staff, faculty” returns records with null/empty values |
| 6 |
| N/A | records with null / empty values are returned e.g., “Instance – Language” not in to “English, French” returns records with null/empty values | |
| 7 | is null / empty |
| null / empty values are returned when value is set to “true” | records with null / empty values are returned when value is set to “true” e.g., “User – Active” is null/empty “True” returns records with null/empty values |
| 8 | null / empty values are not returned when value is set to “false” | records with null / empty values are not returned when value is set to “false” e.g., “User – Active” is null/empty “False” does not return records with null/empty values | ||
| 9 |
| null / empty values are returned when value is set to “true” | null / empty values are returned when value is set to “true” - if any of the values for the field are empty, the record matches e.g., “Instance – Contributors – Type, free text” is null/empty “True” returns a record with two Contributors, one with a populated “Type, free text” and one null or empty “Type, free text” | |
| 10 | null / empty values are not returned when value is set to “false” (note: Sunflower only supported querying arrays of strings with defined values) | null / empty values are not returned when value is set to “false” - only matches if all of the values for the field are non-empty e.g., “Instance – Contributors – Type, free text” is null/empty “False” does not return the record with two Contributors, one with a populated “Type, free text” and one null or empty “Type, free text” | ||
| 11 | not contains all |
| null / empty values are returned | N/A This operator is not available in Trillium |
| 12 | not contains any |
| null / empty values are returned | N/A The equivalent operator in Trillium is “not in” |
“Staff suppress” and “Suppress from discovery” fields are handled different from all other Boolean fields: when those specific fields are empty, they are treated as “False.”
See more details of that behavior in this Jira comment: https://folio-org.atlassian.net/browse/MODFQMMGR-422
Related Jira issues:
Will be addressed in Trillium:
https://folio-org.atlassian.net/browse/MODFQMMGR-753 - scheduled for Trillium to resolve inconsistency in row 1 above
https://folio-org.atlassian.net/browse/MODFQMMGR-754 - scheduled for Trillium to resolve inconsistency in rows 5 / 6 above
https://folio-org.atlassian.net/browse/MODFQMMGR-334 - performance testing scheduled in Trillium to make sure there isn’t an unexpected performance issue
https://folio-org.atlassian.net/browse/MODFQMMGR-540- will be resolved by the other stories in Trillium
https://folio-org.atlassian.net/browse/MODFQMMGR-729- will be resolved by other stories in Trillium
https://folio-org.atlassian.net/browse/MODFQMMGR-718- will be resolved by other stories in Trillium
https://folio-org.atlassian.net/browse/MODFQMMGR-966- resolved in Trillium; relates to rows 9 & 10 above
https://folio-org.atlassian.net/browse/MODFQMMGR-948 - issue was related MODFQMMGR-718
Closed / won’t do
https://folio-org.atlassian.net/browse/MODFQMMGR-717 - closed as won’t do
https://folio-org.atlassian.net/browse/MODFQMMGR-682 - closed as won’t do
https://folio-org.atlassian.net/browse/MODFQMMGR-725 - closed as won’t do