test(mongodb): failing repro for ODM nullable field unset#8298
Open
soyuka wants to merge 1 commit into
Open
Conversation
ODM's Field nullable flag controls whether a null value is persisted as an explicit null key or the key is omitted from the document — it does not mean the field rejects null. DoctrineExtractor::getType() feeds ClassMetadata::isNullable() into the TypeInfo Type nullable flag, so a plain #[Field(type:'string')] (default nullable=false) yields a non-nullable Type and PATCH {"field": null} fails with a type error.
This is the failing repro the maintainer requested before deciding on the fix direction. No production code is changed; the fix is pending a design decision.
Refs api-platform#3746
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Failing-repro PR requested by @soyuka in the design discussion for #3746.
In Doctrine MongoDB ODM, a
#[Field]'snullableflag does not mean "the field may hold null". It controls whether a PHPnullis persisted as an explicitnullkey or the key is omitted from the document (nullable=false, the default = omit). Every ODM field can therefore receivenull.src/Doctrine/Odm/PropertyInfo/DoctrineExtractor::getType()feedsClassMetadata::isNullable()into the TypeInfoTypenullable flag, so a plain#[Field(type: 'string')]yields a non-nullable Type. As a resultPATCH {"field": null}is rejected withThe type of the "field" attribute must be "string", "NULL" given.instead of unsetting the field.Scope
Per the maintainer's note ("I dont care much about property info only type info path"), this targets the TypeInfo
getType()path only. The legacygetTypes()property-info path is untouched.This PR
A single failing test (
testExtractScalarFieldPermitsNull) asserting the expected-correct behavior — an ODM scalar field's extracted type permits null. It fails on current4.3HEAD, demonstrating the bug.No production code is changed. The fix direction is pending a maintainer decision between the three options posted in the validation thread (always-nullable for ODM scalars / defer to PHP property type / drop the flag).
Refs #3746