Repository navigation
Elasticsearch Denormalizer returns null for fields composed of two ore more words (ex. firstName) #4053
Description
API Platform version(s) affected: 2.6.3
Description
As mentioned in summary there is an issue with getting data form Elasticsearch. It reproduced when I tried to get data for fields that composed of several words (ex. firstName, createdAt etc.) Result the same for jsonld and graphql normalizers and for nested objects as well.
How to reproduce
- Enable support for Elasticsearch
- Create model and field with two words name
- Store some data
- Try to get data by using jsonld or graphql formats
- Result for fields with two words name will be empty
Possible Solution
There is could be a bug with comparing allowedAttributes to attributes from ES result. Method getAllowedAttributes of AbstractObjectNormalizer returns allowed attributes in camel case whereas attributes in ES source wrote in snake_case
Activity
[-]Elasticsearch Denormlizer returns null for fields composed of two ore more words (ex. firstName)[/-][+]Elasticsearch Denormalizer returns null for fields composed of two ore more words (ex. firstName)[/+]meyerbaptiste commentedon Feb 11, 2021
I think we definitely have a problem with documents with fields in snake case (cf. api-platform/docs#1204 (comment)). I will investigate this in the next few weeks.
imaximius commentedon Feb 11, 2021
Thanks a lot. I'll be waiting
lwillems commentedon Mar 2, 2022
@imaximius i can confirm issue comes from getAllowedAttributes comparison (snakeCase in ES vs CameCasel in models)
@meyerbaptiste got ideas to solve this ?
Regards
soyuka commentedon Jun 11, 2026
This has been resolved:
InnerFieldsNameConverter(src/Elasticsearch/Serializer/NameConverter/InnerFieldsNameConverter.php) now converts snake_case ES fields back to camelCase during denormalization, andtests/Functional/Elasticsearch/ReadTest.phpcovers multi-word fields likefirstName/lastName. Verified on current4.3HEAD. Closing as fixed — please reopen if you still reproduce on a recent release.soyuka commentedon Sep 30, 2026
My previous comment was wrong, sorry: nothing converts snake_case fields by default, the
InnerFieldsNameConverterfallback never applies and the functional tests use camelCase fields. See #8470.To map snake_case documents you need to configure a name converter, the docs are updated in api-platform/docs#2349. Note that the converter also applies to the field names used by filters and sorting.