[Validator][Doctrine] Add docs for automatic validation #11132

dunglas · 2019-03-11T11:57:58Z

See symfony/symfony#27735

doctrine.rst

teohhanhui

versionadded is missing?

doctrine.rst

@Orm

…alidation (dunglas) This PR was merged into the 4.3-dev branch. Discussion ---------- [Validator][DoctrineBridge][FWBundle] Automatic data validation | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no  | Deprecations? | no  | Tests pass? | yes  | Fixed tickets | n/a  | License | MIT | Doc PR | symfony/symfony-docs#11132 This feature automatically adds some validation constraints by inferring existing metadata. To do so, it uses the PropertyInfo component and Doctrine metadata, but it has been designed to be easily extendable. Example: ```php use Doctrine\ORM\Mapping as ORM; /** * @Orm\Entity */ class Dummy { /** * @Orm\Id * @Orm\GeneratedValue(strategy="AUTO") * @Orm\Column(type="integer") */ public $id; /** * @Orm\Column(nullable=true) */ public $columnNullable; /** * @Orm\Column(length=20) */ public $columnLength; /** * @Orm\Column(unique=true) */ public $columnUnique; } $manager = $this->managerRegistry->getManager(); $manager->getRepository(Dummy::class); $firstOne = new Dummy(); $firstOne->columnUnique = 'unique'; $firstOne->columnLength = '0'; $manager->persist($firstOne); $manager->flush(); $dummy = new Dummy(); $dummy->columnNullable = 1; // type mistmatch $dummy->columnLength = '012345678901234567890'; // too long $dummy->columnUnique = 'unique'; // not unique $res = $this->validator->validate($dummy); dump((string) $res); /* Object(App\Entity\Dummy).columnUnique:\n This value is already used. (code 23bd9dbf-6b9b-41cd-a99e-4844bcf3077f)\n Object(App\Entity\Dummy).columnLength:\n This value is too long. It should have 20 characters or less. (code d94b19cc-114f-4f44-9cc4-4138e80a87b9)\n Object(App\Entity\Dummy).id:\n This value should not be null. (code ad32d13f-c3d4-423b-909a-857b961eb720)\n Object(App\Entity\Dummy).columnNullable:\n This value should be of type string. (code ba785a8c-82cb-4283-967c-3cf342181b40)\n */ ``` It also works for DTOs: ```php class MyDto { /** @var string */ public $name; } $dto = new MyDto(); $dto->name = 1; // type error dump($validator->validate($dto)); /* Object(MyDto).name:\n This value should be of type string. (code ba785a8c-82cb-4283-967c-3cf342181b40)\n */ ``` Supported constraints currently are: * `@NotNull` (using PropertyInfo type extractor, so supports Doctrine metadata, getters/setters and PHPDoc) * `@Type` (using PropertyInfo type extractor, so supports Doctrine metadata, getters/setters and PHPDoc) * `@UniqueEntity` (using Doctrine's `unique` metadata) * `@Length` (using Doctrine's `length` metadata) Many users don't understand that the Doctrine mapping doesn't validate anything (it's just a hint for the schema generator). It leads to usability and security issues (that are not entirely fixed by this PR!!). Even the ones who add constraints often omit important ones like `@Length`, or `@Type` (important when building web APIs). This PR aims to improve things a bit, and ease the development process in RAD and when prototyping. It provides an upgrade path to use proper validation constraints. I plan to make it opt-in, disabled by default, but enabled in the default Flex recipe. (= off by default when using components, on by default when using the full stack framework) TODO: * [x] Add configuration flags * [x] Move the Doctrine-related DI logic from the extension to DoctrineBundle: doctrine/DoctrineBundle#831 * [x] Commit the tests Commits ------- 2d64e703c2 [Validator][DoctrineBridge][FWBundle] Automatic data validation

@Orm

…alidation (dunglas) This PR was merged into the 4.3-dev branch. Discussion ---------- [Validator][DoctrineBridge][FWBundle] Automatic data validation | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no  | Deprecations? | no  | Tests pass? | yes  | Fixed tickets | n/a  | License | MIT | Doc PR | symfony/symfony-docs#11132 This feature automatically adds some validation constraints by inferring existing metadata. To do so, it uses the PropertyInfo component and Doctrine metadata, but it has been designed to be easily extendable. Example: ```php use Doctrine\ORM\Mapping as ORM; /** * @Orm\Entity */ class Dummy { /** * @Orm\Id * @Orm\GeneratedValue(strategy="AUTO") * @Orm\Column(type="integer") */ public $id; /** * @Orm\Column(nullable=true) */ public $columnNullable; /** * @Orm\Column(length=20) */ public $columnLength; /** * @Orm\Column(unique=true) */ public $columnUnique; } $manager = $this->managerRegistry->getManager(); $manager->getRepository(Dummy::class); $firstOne = new Dummy(); $firstOne->columnUnique = 'unique'; $firstOne->columnLength = '0'; $manager->persist($firstOne); $manager->flush(); $dummy = new Dummy(); $dummy->columnNullable = 1; // type mistmatch $dummy->columnLength = '012345678901234567890'; // too long $dummy->columnUnique = 'unique'; // not unique $res = $this->validator->validate($dummy); dump((string) $res); /* Object(App\Entity\Dummy).columnUnique:\n This value is already used. (code 23bd9dbf-6b9b-41cd-a99e-4844bcf3077f)\n Object(App\Entity\Dummy).columnLength:\n This value is too long. It should have 20 characters or less. (code d94b19cc-114f-4f44-9cc4-4138e80a87b9)\n Object(App\Entity\Dummy).id:\n This value should not be null. (code ad32d13f-c3d4-423b-909a-857b961eb720)\n Object(App\Entity\Dummy).columnNullable:\n This value should be of type string. (code ba785a8c-82cb-4283-967c-3cf342181b40)\n */ ``` It also works for DTOs: ```php class MyDto { /** @var string */ public $name; } $dto = new MyDto(); $dto->name = 1; // type error dump($validator->validate($dto)); /* Object(MyDto).name:\n This value should be of type string. (code ba785a8c-82cb-4283-967c-3cf342181b40)\n */ ``` Supported constraints currently are: * `@NotNull` (using PropertyInfo type extractor, so supports Doctrine metadata, getters/setters and PHPDoc) * `@Type` (using PropertyInfo type extractor, so supports Doctrine metadata, getters/setters and PHPDoc) * `@UniqueEntity` (using Doctrine's `unique` metadata) * `@Length` (using Doctrine's `length` metadata) Many users don't understand that the Doctrine mapping doesn't validate anything (it's just a hint for the schema generator). It leads to usability and security issues (that are not entirely fixed by this PR!!). Even the ones who add constraints often omit important ones like `@Length`, or `@Type` (important when building web APIs). This PR aims to improve things a bit, and ease the development process in RAD and when prototyping. It provides an upgrade path to use proper validation constraints. I plan to make it opt-in, disabled by default, but enabled in the default Flex recipe. (= off by default when using components, on by default when using the full stack framework) TODO: * [x] Add configuration flags * [x] Move the Doctrine-related DI logic from the extension to DoctrineBundle: doctrine/DoctrineBundle#831 * [x] Commit the tests Commits ------- 2d64e703c2 [Validator][DoctrineBridge][FWBundle] Automatic data validation

@Orm

…alidation (dunglas) This PR was merged into the 4.3-dev branch. Discussion ---------- [Validator][DoctrineBridge][FWBundle] Automatic data validation | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no  | Deprecations? | no  | Tests pass? | yes  | Fixed tickets | n/a  | License | MIT | Doc PR | symfony/symfony-docs#11132 This feature automatically adds some validation constraints by inferring existing metadata. To do so, it uses the PropertyInfo component and Doctrine metadata, but it has been designed to be easily extendable. Example: ```php use Doctrine\ORM\Mapping as ORM; /** * @Orm\Entity */ class Dummy { /** * @Orm\Id * @Orm\GeneratedValue(strategy="AUTO") * @Orm\Column(type="integer") */ public $id; /** * @Orm\Column(nullable=true) */ public $columnNullable; /** * @Orm\Column(length=20) */ public $columnLength; /** * @Orm\Column(unique=true) */ public $columnUnique; } $manager = $this->managerRegistry->getManager(); $manager->getRepository(Dummy::class); $firstOne = new Dummy(); $firstOne->columnUnique = 'unique'; $firstOne->columnLength = '0'; $manager->persist($firstOne); $manager->flush(); $dummy = new Dummy(); $dummy->columnNullable = 1; // type mistmatch $dummy->columnLength = '012345678901234567890'; // too long $dummy->columnUnique = 'unique'; // not unique $res = $this->validator->validate($dummy); dump((string) $res); /* Object(App\Entity\Dummy).columnUnique:\n This value is already used. (code 23bd9dbf-6b9b-41cd-a99e-4844bcf3077f)\n Object(App\Entity\Dummy).columnLength:\n This value is too long. It should have 20 characters or less. (code d94b19cc-114f-4f44-9cc4-4138e80a87b9)\n Object(App\Entity\Dummy).id:\n This value should not be null. (code ad32d13f-c3d4-423b-909a-857b961eb720)\n Object(App\Entity\Dummy).columnNullable:\n This value should be of type string. (code ba785a8c-82cb-4283-967c-3cf342181b40)\n */ ``` It also works for DTOs: ```php class MyDto { /** @var string */ public $name; } $dto = new MyDto(); $dto->name = 1; // type error dump($validator->validate($dto)); /* Object(MyDto).name:\n This value should be of type string. (code ba785a8c-82cb-4283-967c-3cf342181b40)\n */ ``` Supported constraints currently are: * `@NotNull` (using PropertyInfo type extractor, so supports Doctrine metadata, getters/setters and PHPDoc) * `@Type` (using PropertyInfo type extractor, so supports Doctrine metadata, getters/setters and PHPDoc) * `@UniqueEntity` (using Doctrine's `unique` metadata) * `@Length` (using Doctrine's `length` metadata) Many users don't understand that the Doctrine mapping doesn't validate anything (it's just a hint for the schema generator). It leads to usability and security issues (that are not entirely fixed by this PR!!). Even the ones who add constraints often omit important ones like `@Length`, or `@Type` (important when building web APIs). This PR aims to improve things a bit, and ease the development process in RAD and when prototyping. It provides an upgrade path to use proper validation constraints. I plan to make it opt-in, disabled by default, but enabled in the default Flex recipe. (= off by default when using components, on by default when using the full stack framework) TODO: * [x] Add configuration flags * [x] Move the Doctrine-related DI logic from the extension to DoctrineBundle: doctrine/DoctrineBundle#831 * [x] Commit the tests Commits ------- 2d64e703c2 [Validator][DoctrineBridge][FWBundle] Automatic data validation

@Orm

…alidation (dunglas) This PR was merged into the 4.3-dev branch. Discussion ---------- [Validator][DoctrineBridge][FWBundle] Automatic data validation | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no  | Deprecations? | no  | Tests pass? | yes  | Fixed tickets | n/a  | License | MIT | Doc PR | symfony/symfony-docs#11132 This feature automatically adds some validation constraints by inferring existing metadata. To do so, it uses the PropertyInfo component and Doctrine metadata, but it has been designed to be easily extendable. Example: ```php use Doctrine\ORM\Mapping as ORM; /** * @Orm\Entity */ class Dummy { /** * @Orm\Id * @Orm\GeneratedValue(strategy="AUTO") * @Orm\Column(type="integer") */ public $id; /** * @Orm\Column(nullable=true) */ public $columnNullable; /** * @Orm\Column(length=20) */ public $columnLength; /** * @Orm\Column(unique=true) */ public $columnUnique; } $manager = $this->managerRegistry->getManager(); $manager->getRepository(Dummy::class); $firstOne = new Dummy(); $firstOne->columnUnique = 'unique'; $firstOne->columnLength = '0'; $manager->persist($firstOne); $manager->flush(); $dummy = new Dummy(); $dummy->columnNullable = 1; // type mistmatch $dummy->columnLength = '012345678901234567890'; // too long $dummy->columnUnique = 'unique'; // not unique $res = $this->validator->validate($dummy); dump((string) $res); /* Object(App\Entity\Dummy).columnUnique:\n This value is already used. (code 23bd9dbf-6b9b-41cd-a99e-4844bcf3077f)\n Object(App\Entity\Dummy).columnLength:\n This value is too long. It should have 20 characters or less. (code d94b19cc-114f-4f44-9cc4-4138e80a87b9)\n Object(App\Entity\Dummy).id:\n This value should not be null. (code ad32d13f-c3d4-423b-909a-857b961eb720)\n Object(App\Entity\Dummy).columnNullable:\n This value should be of type string. (code ba785a8c-82cb-4283-967c-3cf342181b40)\n */ ``` It also works for DTOs: ```php class MyDto { /** @var string */ public $name; } $dto = new MyDto(); $dto->name = 1; // type error dump($validator->validate($dto)); /* Object(MyDto).name:\n This value should be of type string. (code ba785a8c-82cb-4283-967c-3cf342181b40)\n */ ``` Supported constraints currently are: * `@NotNull` (using PropertyInfo type extractor, so supports Doctrine metadata, getters/setters and PHPDoc) * `@Type` (using PropertyInfo type extractor, so supports Doctrine metadata, getters/setters and PHPDoc) * `@UniqueEntity` (using Doctrine's `unique` metadata) * `@Length` (using Doctrine's `length` metadata) Many users don't understand that the Doctrine mapping doesn't validate anything (it's just a hint for the schema generator). It leads to usability and security issues (that are not entirely fixed by this PR!!). Even the ones who add constraints often omit important ones like `@Length`, or `@Type` (important when building web APIs). This PR aims to improve things a bit, and ease the development process in RAD and when prototyping. It provides an upgrade path to use proper validation constraints. I plan to make it opt-in, disabled by default, but enabled in the default Flex recipe. (= off by default when using components, on by default when using the full stack framework) TODO: * [x] Add configuration flags * [x] Move the Doctrine-related DI logic from the extension to DoctrineBundle: doctrine/DoctrineBundle#831 * [x] Commit the tests Commits ------- 2d64e70 [Validator][DoctrineBridge][FWBundle] Automatic data validation

doctrine.rst

OskarStark · 2019-03-31T13:44:46Z

The code is merged, so I removed the label.

dunglas · 2019-03-31T15:44:57Z

Still needs doctrine/DoctrineBundle#938 before merge.

doctrine.rst

wouterj · 2019-04-06T14:12:36Z

I think it would be nicer to move this new section to a complete new article, linked at the bottom of the guide. It's not really a base feature we should explain in Doctrine imo. Ideally, we should make the main guides as short as possible.

dunglas · 2019-04-06T14:21:28Z

@wouterj But it will be enabled by default. Shouldn't we at least reference it in this guide?
@OskarStark I'll do the change as soon as I'll be back from vacations, thanks for the review!!

sylfabre · 2019-05-09T06:47:42Z

@dunglas thank you for this new feature.
Do you plan to add more documentation on how to extend it?

My use-case:

we have developed at AssoConnect a similar logic to valid our DTOs and entities
we have custom Doctrine types (like email, iban, ...) to enforce consistency in the database structure
we use these custom types for validation as well (like email => EmailValidator)
we would like to switch to your feature as soon as Symfony 4.3 is released

dunglas · 2019-05-09T09:29:20Z

@sylfabre thanks! Unfortunately I don't think I'll have the time to add such docs anytime soon, but I'll be glad to help someone writing it.
In a nutshell, you have to implement the LoaderInterface interface and to register this loader with the validator.auto_mapper tag.

You can see how it's done for Doctrine:

the loader: https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/Validator/DoctrineLoader.php
the DI wiring in DoctrineBundle: https://github.com/doctrine/DoctrineBundle/blob/master/DependencyInjection/DoctrineExtension.php#L797-L807

I hope this helps.

javiereguiluz · 2019-05-31T08:50:32Z

This was finally merged! Thanks Kévin and reviewers! I made all the changes requested by reviewers while merging.

dunglas · 2019-05-31T18:09:58Z

Thank you very much Javier!

nspyke · 2020-04-14T10:35:44Z

@dunglas @javiereguiluz I'm looking for some info on how to configure this feature.
The framework.validation.auto_mapping key is yet to be documented here: https://symfony.com/doc/current/reference/configuration/framework.html#validation

I can see in the feature PR there is mentions of being able to configure it on a class level as well as a class property level (i think?), but again I'm not too sure how to implement this

I'd be happy to make a PR to add this provided I had some instruction on where to find the information about the configuration available

[Validator][Doctrine] Add docs for automatic validation

28721d5

carsonbot added Status: Needs Review Validator Doctrine labels Mar 11, 2019

dunglas mentioned this pull request Mar 11, 2019

[Validator][DoctrineBridge][FWBundle] Automatic data validation symfony/symfony#27735

Merged

3 tasks

dkarlovi reviewed Mar 11, 2019

View reviewed changes

doctrine.rst Outdated Show resolved Hide resolved

javiereguiluz approved these changes Mar 11, 2019

View reviewed changes

doctrine.rst Outdated Show resolved Hide resolved

doctrine.rst Show resolved Hide resolved

carsonbot added Status: Reviewed and removed Status: Needs Review labels Mar 11, 2019

Review

f7b26a0

dkarlovi approved these changes Mar 11, 2019

View reviewed changes

teohhanhui suggested changes Mar 11, 2019

View reviewed changes

carsonbot added Status: Needs Work and removed Status: Reviewed labels Mar 11, 2019

versionadded

0d68e50

carsonbot added Status: Needs Review and removed Status: Needs Work labels Mar 11, 2019

wouterj added the Waiting Code Merge Docs for features pending to be merged label Mar 16, 2019

OskarStark reviewed Mar 20, 2019

View reviewed changes

doctrine.rst Outdated Show resolved Hide resolved

doctrine.rst Outdated Show resolved Hide resolved

noniagriconomie reviewed Mar 22, 2019

View reviewed changes

doctrine.rst Show resolved Hide resolved

xabbuh added this to the next milestone Mar 22, 2019

Review comments

6a66092

OskarStark reviewed Mar 31, 2019

View reviewed changes

doctrine.rst Outdated Show resolved Hide resolved

OskarStark removed the Waiting Code Merge Docs for features pending to be merged label Mar 31, 2019

Fix return type mistake

fbe3e8b

OskarStark approved these changes Mar 31, 2019

View reviewed changes

carsonbot added Status: Reviewed and removed Status: Needs Review labels Mar 31, 2019

apfelbox reviewed Apr 1, 2019

View reviewed changes

doctrine.rst Show resolved Hide resolved

OskarStark added the On hold label Apr 1, 2019

OskarStark reviewed Apr 2, 2019

View reviewed changes

doctrine.rst Show resolved Hide resolved

wouterj added Status: Needs Work and removed On hold Status: Reviewed labels Apr 6, 2019

javiereguiluz modified the milestones: next, 4.3 May 9, 2019

xabbuh changed the base branch from master to 4.3 May 9, 2019 07:43

javiereguiluz added Status: Reviewed and removed Status: Needs Work labels May 31, 2019

javiereguiluz closed this in 87d48fa May 31, 2019

dunglas mentioned this pull request Nov 7, 2019

[Validator] Enable auto mapping by default symfony/recipes#664

Closed

This was referenced Apr 23, 2023

[Validator][Doctrine] Add Note That Automatic Validation is Disabled by Default #18245

Closed

[Validation][FrameworkBundle] Add auto_mapping config #12728

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Validator][Doctrine] Add docs for automatic validation #11132

[Validator][Doctrine] Add docs for automatic validation #11132

dunglas commented Mar 11, 2019

teohhanhui left a comment

OskarStark commented Mar 31, 2019

dunglas commented Mar 31, 2019

wouterj commented Apr 6, 2019

dunglas commented Apr 6, 2019

sylfabre commented May 9, 2019

dunglas commented May 9, 2019

javiereguiluz commented May 31, 2019

dunglas commented May 31, 2019

nspyke commented Apr 14, 2020

[Validator][Doctrine] Add docs for automatic validation #11132

[Validator][Doctrine] Add docs for automatic validation #11132

Conversation

dunglas commented Mar 11, 2019

teohhanhui left a comment

Choose a reason for hiding this comment

OskarStark commented Mar 31, 2019

dunglas commented Mar 31, 2019

wouterj commented Apr 6, 2019

dunglas commented Apr 6, 2019

sylfabre commented May 9, 2019

dunglas commented May 9, 2019

javiereguiluz commented May 31, 2019

dunglas commented May 31, 2019

nspyke commented Apr 14, 2020