-
-
Notifications
You must be signed in to change notification settings - Fork 895
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deeply-nested filters don't work with Elasticsearch #5642
Labels
Comments
colinodell
added a commit
to colinodell/api-platform-core
that referenced
this issue
Jun 29, 2023
colinodell
added a commit
to colinodell/api-platform-core
that referenced
this issue
Jun 29, 2023
colinodell
added a commit
to colinodell/api-platform-core
that referenced
this issue
Jun 29, 2023
colinodell
added a commit
to colinodell/api-platform-core
that referenced
this issue
Jun 29, 2023
colinodell
added a commit
to colinodell/api-platform-core
that referenced
this issue
Jun 29, 2023
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
jonnyeom
pushed a commit
to jonnyeom/api-platform-core
that referenced
this issue
Sep 13, 2023
soyuka
pushed a commit
that referenced
this issue
Sep 14, 2023
* chore(elasticsearch): define a valid, known type for 'baz' * fix(elasticsearch): fix nested object paths (api-platform/api-platform#1375) * fix(elasticsearch): support additional nesting within collections (#5642) --------- Co-authored-by: Colin O'Dell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
API Platform version(s) affected: 2.6.8 (and likely earlier) through 3.x
Description
MatchFilter
andTermFilter
do not properly support multi-level nested fields in Elasticsearch if the top level is a collection.What Works
It seems to work fine if the top level is an object. For example, given this sample document from the docs linked above:
Asking API Platform to filter on
driver.vehicle.model
would generate a valid, working query like this:Interestingly, the Elasticsearch docs suggest the query should instead be doubly-nested like this:
But I'm assuming ES will happily accept either version. Regardless, everything described above seems to work just fine.
What's Broken
However, if we modify the structure to have an array of
drivers
as the top-level property like this:Attempting to filter on
drivers.vehicle.model
generates this query:Which fails to match any documents because the
path
is missing the.vehicle
part. Manually adding the.vehicle
part causes the expected documents to appear in the results:Using a proper deeply-nested query also works (but API Platform won't generate this):
Likely Cause
I think the current behavior is caused by
FieldDatatypeTrait::getNestedFieldPath()
never recursively calling itself when the top-level type is a collection. It will never check the rest of the path to see if it might be a nested object.How to reproduce
I don't have a reproducer for how the query fails to work in Elasticsearch, but I did tweak
TermFilterTest::testApplyWithNestedProperty()
to demonstrate the unexpected query:Possible Solution
First, fix
FieldDatatypeTrait::getNestedFieldPath()
so it returns the complete parent path.Once that's done, modify
MatchFilter::getQuery()
andTermFilter::getQuery()
so that they return deeplynested
queries as shown in the Elasticsearch documentation. This seems "more correct" than the current approach of only using onenested
key regardless of how deeply nested the parameter actually is.Additional Context
api-platform/api-platform#1375 describes an issue with filtering nested properties where
getNestedFieldPath()
is also a suspected culprit. My case seems different because the top-level item in my path is a collection and not an object - the execution path is very different.The text was updated successfully, but these errors were encountered: