Create entry requires field name in camelCase

[Toreno96]

Steps to reproduce

1. Create content model (e.g. "foo") with field pg_rating (multiple words in snake_case) in Contentful.

2. Try to create a new entry:

   new_entry = environment.entries().create(
       'new_entry_id',
       {"content_type_id": "foo", "fields": {"pg_rating": {"en-US": "value"}}}
   )

Encountered behavior

An error is raised:

...
contentful_management.errors.UnprocessableEntityError: HTTP status code: 422
Message: No field with id "pg_rating" found.
Details:
        * Name: unknown - Path: '['fields', 'pg_rating']'

Expected behavior

Entry is created, the current value of its pg_rating field is value.

Workaround

When creating a new entry, field name has to be written in camelCase:

new_entry = environment.entries().create(
     'new_entry_id',
     {"content_type_id": "foo", "fields": {"pgRating": {"en-US": "value"}}}
)

That's the underlying issue with API, not SDK, as I tried to make direct request to the API using httpie and it also returns an error:

{
    "details": {
        "errors": [
            {
                "name": "unknown",
                "path": [
                    "fields",
                    "pg_rating"
                ]
            }
        ]
    },
    "message": "No field with id \"pg_rating\" found.",
    "requestId": "f72e32ec9560123245887252d1c9ee13",
    "sys": {
        "id": "UnknownField",
        "type": "Error"
    }
}

Suggested solutions

Implement workaround in SDK

If it's easier to fix that here than in API.

Especially that the issue introduces inconsistency; during update it is actually not possible to use camelCase, snake_case is required there:

(Pdb) entry.pg_rating
'value'
(Pdb) entry.pgRating
*** AttributeError: 'Entry' object has no attribute 'pgRating'

Document the issue

I found no info about how multiword field names are handled, neither in docs of SDK, nor in docs of API.

There's no example if user should use snake_case or camelCase, or what.

If it's non-trivial to implement a workaround in SDK or fix in API, then documenting it explicitly would be at least something.

[rubydog]

Hey, thanks for reporting the issue.



I am looking into it. I will get back to you if I need more details.

Cheers

[martinezpl]

I encountered this issue completely upside down. Parameters of my content type are being converted to snake case after retrieving 🤦‍♂️

CONTENTFUL_CONTENT_TYPE = (
    Client(CONTENTFUL_KEY).content_types(SPACE_ID, ENVIRONMENT).find(CONTENT_TYPE)
)

entry = CONTENTFUL_CONTENT_TYPE.entries().create("test", {"fields": {"paramOne": {"en-US": "one"}}})
entry.publish()

entry = CONTENTFUL_CONTENT_TYPE.entries().find("test")

print(entry.fields())
# {"id": "test", "param_one": "one"}

[rubydog]

Hi @martinezpl I am checking with the product team if there is any standard spec internally to name fields. I will let you know as soon as I know.

Cheers.

[rubydog]

Hi @Toreno96 and @martinezpl,

I've been looking into this issue more closely, and it appears that the inconsistency with Contentful's API can be easily resolved by converting the naming convention to camelCase. However, before implementing this change, I'd like to delve deeper into the reasoning behind the decision to use snake_case in the first place.

Considering that the library already has an existing user base and changing to camelCase would break the current behavior, we need to exercise extra caution. We want to ensure that the benefits of the change outweigh the potential disruption it may cause for our users.

I'll continue my investigation to gather more insights.

Cheers

[Toreno96]

@rubydog Thank you for looking into the issue. I appreciate you coming back to this.

it appears that the inconsistency with Contentful's API can be easily resolved by converting the naming convention to camelCase. However, before implementing this change, I'd like to delve deeper into the reasoning behind the decision to use snake_case in the first place.

I don't understand how that would work for my specific use-case, tho? The issue I've reported is that I wanted and expected to use snake_case instead of camelCase in the first place, so converting the naming convention to camelCase seem to be like quite the opposite of my need? Or did I misunderstand something?

[martinezpl]

Thank you. @rubydog

Working around that was not an issue (the SDK has utils for converting naming styles).
I just found it weird for the system to modify the names of user's variables and I guess it's kind of irreversible now.