Skip to content

How to Apply only a Subset of all Your Validation Constraints (Validation Groups)

Edit this page

By default, when validating an object all constraints of this class will be checked whether or not they actually pass. In some cases, however, you will need to validate an object against only some constraints on that class. To do this, you can organize each constraint into one or more "validation groups" and then apply validation against one group of constraints.

For example, suppose you have a User class, which is used both when a user registers and when a user updates their contact information later:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// src/Entity/User.php
namespace App\Entity;

use Symfony\Component\Security\Core\User\UserInterface;
use Symfony\Component\Validator\Constraints as Assert;

class User implements UserInterface
{
    #[Assert\Email(groups: ['registration'])]
    private string $email;

    #[Assert\NotBlank(groups: ['registration'])]
    #[Assert\Length(min: 7, groups: ['registration'])]
    private string $password;

    #[Assert\Length(min: 2)]
    private string $city;
}

With this configuration, there are three validation groups:

Default
Contains the constraints in the current class and all referenced classes that belong to no other group. In this example, it only contains the city field.
User
Equivalent to all constraints of the User object in the Default group. This is always the name of the class. The difference between this and Default is explained in How to Sequentially Apply Validation Groups.
registration
This is a custom validation group, so it only contains the constraints that are explicitly associated with it. In this example, only the email and password fields.

Constraints in the Default group of a class are the constraints that have either no explicit group configured or that are configured to a group equal to the class name or the string Default.

Caution

When validating just the User object, there is no difference between the Default group and the User group. But, there is a difference if User has embedded objects. For example, imagine User has an address property that contains some Address object and that you've added the Valid constraint to this property so that it's validated when you validate the User object.

If you validate User using the Default group, then any constraints on the Address class that are in the Default group will be used. But, if you validate User using the User validation group, then only constraints on the Address class with the User group will be validated.

In other words, the Default group and the class name group (e.g. User) are identical, except when the class is embedded in another object that's actually the one being validated.

If you have inheritance (e.g. User extends BaseUser) and you validate with the class name of the subclass (i.e. User), then all constraints in the User and BaseUser will be validated. However, if you validate using the base class (i.e. BaseUser), then only the default constraints in the BaseUser class will be validated.

To tell the validator to use a specific group, pass one or more group names as the third argument to the validate() method:

1
$errors = $validator->validate($author, null, ['registration']);

If no groups are specified, all constraints that belong to the group Default will be applied.

In a full stack Symfony project, you'll usually work with validation indirectly through the form library. For information on how to use validation groups inside forms, see How to Define the Validation Groups to Use.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version