Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Serializer] fix context attribute with serializedName#48661

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
ogizanagi merged 1 commit intosymfony:6.2fromnikophil:serializer/fix/bug-with-context
Dec 16, 2022
Merged

[Serializer] fix context attribute with serializedName#48661

ogizanagi merged 1 commit intosymfony:6.2fromnikophil:serializer/fix/bug-with-context
Dec 16, 2022

Conversation

@nikophil
Copy link
Contributor

QA
Branch?6.2
Bug fix?yes
New feature?no
Deprecations?no
LicenseMIT

Hello,

this PR fixes a bug where the#[Context] attribute is not read in denormalization process when it is used along with#[SerializedName] in a constructor.

In the test I provided, the two dates are not equals without the fix, although the same context is provided.

$params = [];
foreach ($constructorParametersas$constructorParameter) {
$paramName =$constructorParameter->name;
$attributeContext =$this->getAttributeDenormalizationContext($class,$paramName,$context);
Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

heregetAttributeDenormalizationContext() was getting passed$key which represents the serializedName, although we want the name of the property, to access its metadata

@mtarld
Copy link
Contributor

mtarld commentedDec 15, 2022
edited
Loading

It is quite strange that it do the exact opposite of what#46847 does

@nicolas-grekas
Copy link
Member

Let's add a test case that covers the target behavior in#46847, this might help sort this out.

mtarld, nikophil, and dunglas reacted with thumbs up emoji

@nikophil
Copy link
ContributorAuthor

nikophil commentedDec 15, 2022
edited
Loading

@nicolas-grekas code style fixed 👍

I'm not sure what else to test.#46847 says:

I realized we can't use the Context attribute context in anAdvancedNameConverterInterface::denormalize()

but we only pass throughAdvancedNameConverterInterface::normalize() here.

And the PR mentions#46525 which says:

Property specific denormalization context doesn't work when property name in the array being denormalized is different from property name in the class.

which is exactly what my PR does and tests...

Copy link
Member

@dunglasdunglas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM

Copy link
Contributor

@ogizanagiogizanagi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I guess things goes wrong in my mind when reading the bug fix in#46525 and proofreading#46680 after making thesuggestion of adding the attribute-specific context to the name converter.

The diff between#46525 and this is#46525 is iterating the data keys to be denormalized to its properties, while this PR (and originally#46680) goes the other way around, iterating the constructor properties to be normalized to their counterpart in$data.

Anyway, LGTM. Thank you@nikophil

@ogizanagiogizanagi merged commit7df2468 intosymfony:6.2Dec 16, 2022
@fabpotfabpot mentioned this pull requestDec 16, 2022
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas left review comments

@dunglasdunglasdunglas approved these changes

@mtarldmtarldmtarld approved these changes

+1 more reviewer

@ogizanagiogizanagiogizanagi approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

6.2

Development

Successfully merging this pull request may close these issues.

6 participants

@nikophil@mtarld@nicolas-grekas@dunglas@ogizanagi@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp