@@ -358,7 +358,7 @@ and save it::
358
358
public function createProduct(): Response
359
359
{
360
360
// 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)
362
362
$entityManager = $this->getDoctrine()->getManager();
363
363
364
364
$product = new Product();
@@ -421,8 +421,8 @@ is smart enough to know if it should INSERT or UPDATE your entity.
421
421
Validating Objects
422
422
------------------
423
423
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::
426
426
427
427
// src/Controller/ProductController.php
428
428
namespace App\Controller;
@@ -441,8 +441,10 @@ to perform some basic validation tasks::
441
441
public function createProduct(ValidatorInterface $validator): Response
442
442
{
443
443
$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');
446
448
447
449
// ...
448
450
@@ -451,43 +453,42 @@ to perform some basic validation tasks::
451
453
return new Response((string) $errors, 400);
452
454
}
453
455
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
+ // ...
460
457
}
461
458
}
462
459
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
+
463
467
The 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.
481
487
482
488
.. versionadded :: 4.3
483
489
484
490
The automatic validation has been added in Symfony 4.3.
485
491
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
-
491
492
Fetching Objects from the Database
492
493
----------------------------------
493
494
0 commit comments