Search API condition groups are not preserved when Azure filter parameters are built.
When a query contains a nested OR condition group, QueryFilterBuilder::buildQueryFilters() currently merges nested filters into the parent filter list. Later, QueryParamBuilder joins the returned filters with and, which can change the intended logic.
For example, a query intended to filter by (bibcite_year eq 2024 or bibcite_year eq 2025) can be flattened into separate filters and combined as bibcite_year eq 2024 and bibcite_year eq 2025.
The same area also affects multi-value integer fields that are represented in Azure as collections. Those fields must be filtered using Azure's any(...) syntax instead of scalar equality.
1. Configure a Search API Azure AI Search index.
2. Add a Search API query condition group using OR, with two or more conditions.
3. Execute the query and inspect the generated Azure $filter parameter.
4. For the integer collection case, configure a multi-value integer field that is stored in Azure as a collection and filter by one or more values.
Expected result:
Nested condition groups preserve their conjunctions in the generated Azure filter, for example (field_a eq 1 or field_a eq 2). Integer collection fields use field/any(...) syntax.
Actual result:
Nested condition group filters are flattened and can be combined with and. Integer collection fields can be filtered as scalar fields, which is not valid for Azure collection fields.
Refactor condition filter building into a dedicated helper method, preserve nested condition groups by joining them with their own conjunction, and wrap top-level OR groups in parentheses.
Add integer collection filter handling for the affected multi-value integer field.
Attached patch:
preserve-query-filter-groups-and-integer-collections.patch
1. Review the patch.
2. Generalise the integer collection detection so it does not rely on a specific field machine name.
3. Add test coverage for nested OR condition groups and integer collection filters.
None.
None.
None.
None.
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 3592233-preserve-query-filter-groups-7.patch | 6.91 KB | kieran.cott |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #6
kr3ian commentedTested this patch and it works for me
Comment #7
kieran.cottFurther to resolution of https://www.drupal.org/node/3592230, some of this patch/MR is no longer required. However, the underlying issue of QueryParamBuilder flattening a nested OR condition group and combining with AND appears to persist.
MR32 is now updated and the patch rerolled.
Comment #8
jacobsaw commentedComment #9
jacobsaw commentedHi Kieran,
Thank you for creating the issue and proactively addressing the changes from the other MR!
I am going to test this either today or Monday and will move it forward if it looks good. I have a case with nested conditions in my set up I can test against.
Comment #10
jacobsaw commentedComment #11
jacobsaw commentedHi Kieran,
Apologies for the delay, I had to prioritize other work last week and only had time to get to the other issue we collaborated on.
Overall, this looks great! My nested filters were preserved and well formatted.
I am looking into the following error for one of my date fields, the patch I was using before testing yours had the date field without single quotes surrounding it and that seems to be the change causing the error:
Invalid expression: A binary operator with incompatible types was detected. Found operand types 'Edm.DateTimeOffset' and 'Edm.String' for operator kind 'GreaterThanOrEqual'. Parameter name: $filter
Comment #12
jacobsaw commentedThis was what was needed to get rid of that error: 'aais.date_time_offset' => sprintf("%s %s %s", $condition->getField(), $operator, $condition->getValue()),.
Going to do a bit more testing and some other minor changes. Hoping to have this wrapped up this week.
Comment #14
jacobsaw commented