underscore in field name does not work with @Groups #1554

hariszukanovic · 2017-12-07T17:21:04Z

I am using doctrine.orm.naming_strategy.underscore, in generated entities, the member variables are named in snake case.
When using @Groups to select fields, any of the fields with an underscore in their name are missing from the response.
Example: service_index
Any fields that are a single word (no underscore) do not exhibit this problem.
Also, when not using @Groups everything works just fine.

If variables are named in camel case, they appear in the response even when using @Groups and even if the column in the DB is still named in snake case.
Example: serviceIndex

v2.0.11 and v.2.1.4 tested.

The text was updated successfully, but these errors were encountered:

hariszukanovic · 2017-12-10T07:49:06Z

Am I the only one using underscores :) ?
Can anyone please confirm this is a known problem?

colinedmz · 2018-03-13T11:55:32Z

@hariszukanovic : I have the same problem

netsuo · 2018-04-01T20:56:30Z

@hariszukanovic I have the same problem and it even weirder.

Suppose you have a field name entity_id. With @groups, as you stated, it is not returned.

Now, do this:

    /**
     * @ORM\Column(type="integer")
     * @var int
     */
    private $entity_id;


    /**
     * @Groups("get")
     * @var int
     */
    private $entityId;

Notice I just duplicated the variable and set the second camelCase one to @groups and removed the group on the first.

Result: your variable is on the api response named like the second variable even though the colum getter is still on the snake_case one

{
  "@context": "/contexts/Test",
  "@id": "/tests",
  "@type": "hydra:Collection",
  "hydra:member": [
    {
      "@id": "/tests/1",
      "@type": "Test",
      "entityId": 1871912
   }
}

rubiodamian · 2018-05-01T18:47:55Z

Same to me. Super weird bug.

hariszukanovic · 2018-05-01T19:10:21Z

Should this be fixed in the next version?

…

On Tue, 1 May 2018, 20:47 Damián Rubio, ***@***.***> wrote: Same to me. Super weird bug. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1554 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLXKNR9CJaqp512t2aZ2-cY39caM9hqks5tuK3cgaJpZM4Q55u_> .

Simperfit · 2018-05-02T13:56:00Z

Could you please provide a little project based on https://github.com/api-platform/api-platform in order to test this behaviour ?

rubiodamian · 2018-06-01T14:14:08Z

@Simperfit if any field of the ApiResource entity has an underscore "_" the field will be ReadOnly. Is simple as that.

teohhanhui · 2018-06-01T18:53:27Z

I suspect this has to do with how the Symfony PropertyInfo component extracts accessor and mutator methods, specifically:

https://github.com/symfony/symfony/blob/v4.1.0/src/Symfony/Component/PropertyInfo/Extractor/ReflectionExtractor.php#L287

https://github.com/symfony/symfony/blob/v4.1.0/src/Symfony/Component/PropertyInfo/Extractor/ReflectionExtractor.php#L320

If your property name does not follow the convention, you'd have to add the missing property metadata yourself.

hariszukanovic · 2018-06-08T12:20:19Z

Would you have a working example of this (should I call it workaround?)?

Cethy · 2018-09-17T16:20:29Z

I have the same problematic behavior w/ fields prefixed with is* (like isActive) :

the @Groups does not work (field doesn't show in the response) ;
Swagger correctly displays the expected documentation ;
but when group strategy removed, it shows as a field name active in the response ;

If you remove the group strat too, I guess you'll see your field camelized.

EDIT: woops, never mind, i messed up with the getter method.

soyuka · 2019-04-07T08:26:24Z

closing, use custom metadata if the behavior differs from the one expected by the property info as @teohhanhui said

erikkubica · 2019-12-02T14:11:17Z

Even weirder behaviour is that if it´s camel case, api platform returns array of IRIs if its snake case it returs list of objects in some places and in some scenarios and in some it returns objects. My project takes like 2x longer with api platform than without it. Took my few hours to figure out the underscore thing, fixed part of my code, but broke the other part. So i have no idea what to do.

dobrescucristian · 2020-08-13T14:12:32Z

I'm not sure what the "custom metadata" solutions refers to, that only lead me to SQL errors because the DB columns are still "some_thing" and setting the name property in @Orm\Column to "someThing" broke the queries.

But if you find this issue on google because you're naming your Entity properties "some_thing" and they don't show in your API responses, it's because you need to name them "someThing".

If you want "some_thing" in the the API response, do this:

From the docs: https://api-platform.com/docs/core/serialization/#name-conversion

TeLiXj · 2021-01-27T08:18:37Z

Using camel case in variables only is mandatory to develop Symfony bundles or help in the Symfony project. If your project follow PSR-12 (PSR-2 is deprecated) you can choose what do you want for variable names. I always choose snake case and have use a lot of different bundles without problems since Symfony 2, and reflection works fine in all cases.
I don't know how this issue can be closed saying "if the behavior differs from the one expected by the property info" because is a completely correct way to define a entity in Symfony and Doctrine. I hope that you can reconsider your action and try to fix it.
Meanwhile, if you have this problem you can use the groups directly in the setters o getters involved.
You must change from

/**
 * @ORM\Column(type="int")
 * @Groups({"baz:read", "baz:write"})
 */
private $foo_bar;

to

/**
 * @ORM\Column(type="int")
 */
private $foo_bar;

/**
 * @Groups({"baz:read"})
 */
public function getFooBar(): ?int
{
    return $this->foo_bar;
}

/**
 * @Groups({"baz:write"})
 */
public function setFooBar(int $foo_bar): self
{
    $this->foo_bar = $foo_bar;

    return $this;
}

evotodi · 2021-04-09T16:54:44Z

By the way another workaround is a modification to @TeLiXj answer because for me rewriting annotations for 207 properties plus getters and setters was looking like a chore.

/**
* @ORM\Column(type="boolean")
* @Groups({"dataspec:read","dataspec:write"})
*/
private bool $g_heEn = true;

Changed getters and setters from:

public function isGHeEn(): bool
{
	return $this->g_heEn;
}

public function setGHeEn(bool $g_heEn): self
{
	$this->g_heEn = $g_heEn;
	return $this;
}

To (notice the underscore placement):

public function isG_HeEn(): bool
{
	return $this->g_heEn;
}

public function setG_HeEn(bool $g_heEn): self
{
	$this->g_heEn = $g_heEn;
	return $this;
}

And then docs post example shows:

{
  "g_heEn": true
}

And return example shows:

{
  "g_heEn": true,
}

Which is what i was after.
Yes it is not PSR-12 or PSR-2 and it is snakeCamel but when in a pinch.

TeLiXj · 2021-06-28T07:44:01Z

Finally, after update to PHP 8 and move from annotations to attributes works at least on read

… isReadable() when checking snake_case properties (jbtronics) This PR was squashed before being merged into the 6.4 branch. Discussion ---------- [PropertyInfo] Make isWriteable() more consistent with isReadable() when checking snake_case properties | Q | A | ------------- | --- | Branch? | 6.4 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | Related with issues #29933 and #16889 | License | MIT | Doc PR | Currently PropertyInfo is a bit inconsistent in the behavior of isWriteable() and isReadable() when using it with properties in snake_case format, which are only accessible via a getter and setter. To be readable the getter function has to be in camel_case (e.g. `getSnakeCase()`), while the setter function has to remain in the snake case format (e.g. `setSnake_case()`). In this example class: ```php class Dummy { private string $snake_case; public function getSnakeCase(): string { } public function setSnakeCase(string $snake_case): void { } } ```` the property `snake_case` is considered readable like you would expect, but not writeable, even though the property has a useable setter and the value can be actually be modified fine by something like the PropertyAccess component. To make the property actually considered writeable, the setter would need to be named `setSnake_case`, which is pretty inconsistent with the behavior of isReadable and makes it very hard to use this component on snake_case properties. This inconsistencies are caused by the fact, that `isReadable` in ReflectionExtractor uses the `getReadInfo()` function which does a camelization of the property name internally, while the `isWriteable()` function uses the `getMutatorMethod()` function which just perform a capitalization of the first letter. This PR fixes this inconsistencies between isReadable() and isWriteable() by allowing to use a camelCase style setter to be considered writeable, as this is much more common then to use the mix of snake and camelCase currently required. The getWriteInfo() function is not useable here, because it needs both a add and remove Function on collection setters to give proper infos, while the current `isWriteable()` implementation considers a class with just a add or a remove function as writeable. Therefore the property name just gets camelized before being feed into the `getMutatorMethod()`, which gives the desired result. To maximize backwards compatibility, if no camelCase style setter is found, it is still checked for a snake_case setter, so that classes having these, are still considered writeable after the change. The current behavior is causing some inconsistencies in higher level libraries, which rely on this component. In API Platform for example properties in snake_case are considered read only even though they have a (camel case) setter, because of this. See issue: api-platform/core#5641 and api-platform/core#1554 Commits ------- 7c9e6bc [PropertyInfo] Make isWriteable() more consistent with isReadable() when checking snake_case properties

… isReadable() when checking snake_case properties (jbtronics) This PR was squashed before being merged into the 6.4 branch. Discussion ---------- [PropertyInfo] Make isWriteable() more consistent with isReadable() when checking snake_case properties | Q | A | ------------- | --- | Branch? | 6.4 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | Related with issues #29933 and #16889 | License | MIT | Doc PR | Currently PropertyInfo is a bit inconsistent in the behavior of isWriteable() and isReadable() when using it with properties in snake_case format, which are only accessible via a getter and setter. To be readable the getter function has to be in camel_case (e.g. `getSnakeCase()`), while the setter function has to remain in the snake case format (e.g. `setSnake_case()`). In this example class: ```php class Dummy { private string $snake_case; public function getSnakeCase(): string { } public function setSnakeCase(string $snake_case): void { } } ```` the property `snake_case` is considered readable like you would expect, but not writeable, even though the property has a useable setter and the value can be actually be modified fine by something like the PropertyAccess component. To make the property actually considered writeable, the setter would need to be named `setSnake_case`, which is pretty inconsistent with the behavior of isReadable and makes it very hard to use this component on snake_case properties. This inconsistencies are caused by the fact, that `isReadable` in ReflectionExtractor uses the `getReadInfo()` function which does a camelization of the property name internally, while the `isWriteable()` function uses the `getMutatorMethod()` function which just perform a capitalization of the first letter. This PR fixes this inconsistencies between isReadable() and isWriteable() by allowing to use a camelCase style setter to be considered writeable, as this is much more common then to use the mix of snake and camelCase currently required. The getWriteInfo() function is not useable here, because it needs both a add and remove Function on collection setters to give proper infos, while the current `isWriteable()` implementation considers a class with just a add or a remove function as writeable. Therefore the property name just gets camelized before being feed into the `getMutatorMethod()`, which gives the desired result. To maximize backwards compatibility, if no camelCase style setter is found, it is still checked for a snake_case setter, so that classes having these, are still considered writeable after the change. The current behavior is causing some inconsistencies in higher level libraries, which rely on this component. In API Platform for example properties in snake_case are considered read only even though they have a (camel case) setter, because of this. See issue: api-platform/core#5641 and api-platform/core#1554 Commits ------- 7c9e6bc36e [PropertyInfo] Make isWriteable() more consistent with isReadable() when checking snake_case properties

hariszukanovic mentioned this issue Dec 8, 2017

Using groups, properties with underscore always treated as readonly api-platform/api-platform#470

Closed

Simperfit added the bug label May 2, 2018

soyuka closed this as completed Apr 7, 2019

soyuka added the ⭐ EU-FOSSA Hackathon label Apr 7, 2019

bachinblack mentioned this issue Jul 7, 2021

Fields missing in definition of the schema #3608

Closed

This was referenced Sep 19, 2023

[PropertyInfo] Make isWriteable() more consistent with isReadable() when checking snake_case properties symfony/symfony#51697

Merged

APIResource mess with denormalization for underscore property #5641

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

underscore in field name does not work with @Groups #1554

underscore in field name does not work with @Groups #1554

hariszukanovic commented Dec 7, 2017 •

edited by Simperfit

hariszukanovic commented Dec 10, 2017

colinedmz commented Mar 13, 2018

netsuo commented Apr 1, 2018

rubiodamian commented May 1, 2018

hariszukanovic commented May 1, 2018 via email

Simperfit commented May 2, 2018

rubiodamian commented Jun 1, 2018

teohhanhui commented Jun 1, 2018

hariszukanovic commented Jun 8, 2018

Cethy commented Sep 17, 2018 •

edited

soyuka commented Apr 7, 2019

erikkubica commented Dec 2, 2019

dobrescucristian commented Aug 13, 2020

TeLiXj commented Jan 27, 2021

evotodi commented Apr 9, 2021

TeLiXj commented Jun 28, 2021 •

edited

underscore in field name does not work with @Groups #1554

underscore in field name does not work with @Groups #1554

Comments

hariszukanovic commented Dec 7, 2017 • edited by Simperfit

hariszukanovic commented Dec 10, 2017

colinedmz commented Mar 13, 2018

netsuo commented Apr 1, 2018

rubiodamian commented May 1, 2018

hariszukanovic commented May 1, 2018 via email

Simperfit commented May 2, 2018

rubiodamian commented Jun 1, 2018

teohhanhui commented Jun 1, 2018

hariszukanovic commented Jun 8, 2018

Cethy commented Sep 17, 2018 • edited

soyuka commented Apr 7, 2019

erikkubica commented Dec 2, 2019

dobrescucristian commented Aug 13, 2020

TeLiXj commented Jan 27, 2021

evotodi commented Apr 9, 2021

TeLiXj commented Jun 28, 2021 • edited

hariszukanovic commented Dec 7, 2017 •

edited by Simperfit

Cethy commented Sep 17, 2018 •

edited

TeLiXj commented Jun 28, 2021 •

edited