@@ -358,7 +358,7 @@ and save it::
358358 public function createProduct(): Response
359359 {
360360 // you can fetch the EntityManager via $this->getDoctrine()
361- // or you can add an argument to your action: index (EntityManagerInterface $entityManager)
361+ // or you can add an argument to the action: createProduct (EntityManagerInterface $entityManager)
362362 $entityManager = $this->getDoctrine()->getManager();
363363
364364 $product = new Product();
@@ -421,8 +421,8 @@ is smart enough to know if it should INSERT or UPDATE your entity.
421421Validating Objects
422422------------------
423423
424- :doc: `The Symfony validator </validation >` reuses Doctrine metadata
425- to perform some basic validation tasks::
424+ :doc: `The Symfony validator </validation >` reuses Doctrine metadata to perform
425+ some basic validation tasks::
426426
427427 // src/Controller/ProductController.php
428428 namespace App\Controller;
@@ -441,8 +441,10 @@ to perform some basic validation tasks::
441441 public function createProduct(ValidatorInterface $validator): Response
442442 {
443443 $product = new Product();
444- $product->setName(null); // The column in database isn't nullable
445- $product->setPrice('1999'); // Type mismatch, an integer is expected
444+ // This will trigger an error: the column isn't nullable in the database
445+ $product->setName(null);
446+ // This will trigger a type mismatch error: an integer is expected
447+ $product->setPrice('1999');
446448
447449 // ...
448450
@@ -451,43 +453,42 @@ to perform some basic validation tasks::
451453 return new Response((string) $errors, 400);
452454 }
453455
454- // Will not be reached in this example
455- $entityManager = $this->getDoctrine()->getManager();
456- $entityManager->persist($product);
457- $entityManager->flush();
458-
459- return new Response('Saved new product with id '.$product->getId());
456+ // ...
460457 }
461458 }
462459
460+ Although the ``Product `` entity doesn't define any explicit
461+ :doc: `validation configuration </validation >`, Symfony introspects the Doctrine
462+ mapping configuration to infer some validation rules. For example, given that
463+ the ``name `` property can't be ``null `` in the database, a
464+ :doc: `NotNull constraint </reference/constraints/NotNull >` is added automatically
465+ to the property (if it doesn't contain that constraint already).
466+
463467The following table summarizes the mapping between Doctrine metadata and
464- the corresponding validation constraints:
465-
466- +--------------------+-----------------------------------------------------------+-------------------------------------------------------------------------+
467- | Doctrine attribute | Validation constraint | Notes |
468- +====================+===========================================================+=========================================================================+
469- | ``nullable=true `` | :doc: `NotNull </reference/constraints/NotNull >` | Relies on :doc: `the PropertyInfo component </components/property_info >` |
470- +--------------------+-----------------------------------------------------------+-------------------------------------------------------------------------+
471- | ``type `` | :doc: `Type </reference/constraints/Type >` | Relies on :doc: `the PropertyInfo component </components/property_info >` |
472- +--------------------+-----------------------------------------------------------+-------------------------------------------------------------------------+
473- | ``unique=true `` | :doc: `UniqueEntity </reference/constraints/UniqueEntity >` | |
474- +--------------------+-----------------------------------------------------------+-------------------------------------------------------------------------+
475- | ``length `` | :doc: `Length </reference/constraints/Length >` | |
476- +--------------------+-----------------------------------------------------------+-------------------------------------------------------------------------+
477-
478- Because :doc: `the Form component </forms >` as well as `API Platform `_
479- internally use the Validator Component, all your forms
480- and web APIs will also automatically benefit from these default constraints.
468+ the corresponding validation constraints added automatically by Symfony:
469+
470+ ================== ========================================================= =====
471+ Doctrine attribute Validation constraint Notes
472+ ================== ========================================================= =====
473+ ``nullable=false `` :doc: `NotNull </reference/constraints/NotNull >` Requires installing the :doc: `PropertyInfo component </components/property_info >`
474+ ``type `` :doc: `Type </reference/constraints/Type >` Requires installing the :doc: `PropertyInfo component </components/property_info >`
475+ ``unique=true `` :doc: `UniqueEntity </reference/constraints/UniqueEntity >`
476+ ``length `` :doc: `Length </reference/constraints/Length >`
477+ ================== ========================================================= =====
478+
479+ Because :doc: `the Form component </forms >` as well as `API Platform `_ internally
480+ use the Validator component, all your forms and web APIs will also automatically
481+ benefit from these automatic validation constraints.
482+
483+ This automatic validation is a nice feature to improve your productivity, but it
484+ doesn't replace the validation configuration entirely. You still need to add
485+ some :doc: `validation constraints </reference/constraints >` to ensure that data
486+ provided by the user is correct.
481487
482488.. versionadded :: 4.3
483489
484490 The automatic validation has been added in Symfony 4.3.
485491
486- .. tip ::
487-
488- Don't forget to add :doc: `more precise validation constraints </reference/constraints >`
489- to ensure that data provided by the user is correct.
490-
491492Fetching Objects from the Database
492493----------------------------------
493494
0 commit comments