8000 [Validator][Doctrine] Add docs for automatic validation by dunglas · Pull Request #11132 · symfony/symfony-docs · GitHub
[go: up one dir, main page]
Skip to content

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

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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 5 commits into from
Closed

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

wants to merge 5 commits into from

Conversation

dunglas
Copy link
Member
@dunglas dunglas commented Mar 11, 2019

@dunglas dunglas mentioned this pull request Mar 11, 2019
Merged
3 tasks
dkarlovi
dkarlovi reviewed Mar 11, 2019
View reviewed changes
javiereguiluz
javiereguiluz approved these changes Mar 11, 2019
View reviewed changes
teohhanhui
teohhanhui suggested changes Mar 11, 2019
View reviewed changes
Copy link
Contributor
@teohhanhui teohhanhui left a comment

Choose a reason for hiding this comment

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

versionadded is missing?

@wouterj wouterj added the Waiting Code Merge Docs for features pending to be merged label Mar 16, 2019
OskarStark
OskarStark reviewed Mar 20, 2019
View reviewed changes
noniagriconomie
noniagriconomie reviewed Mar 22, 2019
View reviewed changes
@xabbuh xabbuh added this to the next milestone Mar 22, 2019
symfony-splitter pushed a commit to symfony/framework-bundle that referenced this pull request Mar 31, 2019
@fabpot
feature #27735 [Validator][DoctrineBridge][FWBundle] Automatic data v…
ffc4adc 
…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<!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | n/a   <!-- #-prefixed issue number(s), if any -->
| 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] A
10000
dd 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
symfony-splitter pushed a commit to symfony/doctrine-bridge that referenced this pull request Mar 31, 2019
@fabpot
feature #27735 [Validator][DoctrineBridge][FWBundle] Automatic data v…
91c43c7 
…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<!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | n/a   <!-- #-prefixed issue number(s), if any -->
| 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
symfony-splitter pushed a commit to symfony/validator that referenced this pull request Mar 31, 2019
@fabpot
feature #27735 [Validator][DoctrineBridge][FWBundle] Automatic data v…
671dadb 
…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<!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | n/a   <!-- #-prefixed issue number(s), if any -->
| 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
fabpot added a commit to symfony/symfony that referenced this pull request Mar 31, 2019
@fabpot
feature #27735 [Validator][DoctrineBridge][FWBundle] Automatic data v…
7554cf6 
…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<!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | n/a   <!-- #-prefixed issue number(s), if any -->
| 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
OskarStark
OskarStark reviewed Mar 31, 2019
View reviewed changes
@OskarStark OskarStark removed the Waiting Code Merge Docs for features pending to be merged label Mar 31, 2019
@OskarStark
Copy link
Contributor

The code is merged, so I removed the label.

@dunglas
Copy link
Member Author
dunglas commented Mar 31, 2019

Still needs doctrine/DoctrineBundle#938 before merge.

apfelbox
apfelbox reviewed Apr 1, 2019
View reviewed changes
OskarStark
OskarStark reviewed Apr 2, 2019
View reviewed changes
@wouterj
Copy link
Member
wouterj commented Apr 6, 2019

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
Copy link
Member Author
dunglas commented Apr 6, 2019

@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
Copy link
Contributor
sylfabre commented May 9, 2019

@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

@javiereguiluz javiereguiluz modified the milestones: next, 4.3 May 9, 2019
@xabbuh xabbuh changed the base branch from master to 4.3 May 9, 2019 07:43
@dunglas
Copy link
Member Author
dunglas commented May 9, 2019

@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:

I hope this helps.

@javiereguiluz
Copy link
Member

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

@dunglas
Copy link
Member Author
dunglas commented May 31, 2019

Thank you very much Javier!

@dunglas dunglas mentioned this pull request Nov 7, 2019
Closed
@nspyke
Copy link
Contributor
nspyke commented Apr 14, 2020

@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

This was referenced Apr 23, 2023
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@OskarStark OskarStark OskarStark approved these changes

@apfelbox apfelbox apfelbox left review comments

@noniagriconomie noniagriconomie noniagriconomie left review comments

@teohhanhui teohhanhui teohhanhui requested changes

@javiereguiluz javiereguiluz javiereguiluz approved these changes

@dkarlovi dkarlovi dkarlovi approved these changes

Assignees
No one assigned
Labels
Doctrine Status: Reviewed Validator
Projects
None yet
Milestone
4.3
Development

Successfully merging this pull request may close these issues.
0