The UniqueEntity does not work on non-entity objects afaik. However, I think a proper solution would would be to just try and insert, then catch the unique constraint exception and add a form error:

try {
    $this->em->flush();
} catch (UniqueConstraintViolationException $exception) {
    $form->get('username')->addError(new FormError(
        $this->translator->trans('authentication.username.taken', [], 'validators')
    ));
}

Even when the purpose of the entityClass was to execute the query in a different repository (in some cases, such as when using Doctrine inheritance mapping), I wonder if we could expand its scope to apply UniqueEntity() for non-entity objects (being entityClass mandatory in these case).

The target of this constraint is validate that a particular field (or fields) in a Doctrine entity is (are) unique, so what if:

• we use entityClass option (if set) instead of get_class($entity),
• we use PropertyAccess component instead of ReflectionProperty to read the field value from current object (maintain the metadata verification and the DTO fields must be readable too),
• we remove the check about the repository being able to support the current object,

We would have DTO's with multiple UniqueEntity constraints so:

/**
 * @UniqueEntity(fields={"email"}, entityClass="AppBundle\Entity\User")
 * @UniqueEntity(fields={"phone"}, entityClass="AppBundle\Entity\Phone", em="custom")
 */
class RegisterDTO
{
    /** @var string */
    private $email;

    /** @var string */
    private $phone;
    
    //...
}

Is it something we want/can to support?

#14917 related

ping @ogizanagi, @HeahDude

@yceruto I considered something similar in the past; I wasn't sure about reusing the same constraint but now I'd say it makes sense. And the feature would be particularly useful for validating commands (command bus) for instance.

But we will also need a mapping between the DTOs fields and the targeted entity fields as their naming might slightly differ.

Foolish example:

/**
 * @UniqueEntity(fields={"userEmail": "email"}, entityClass="AppBundle\Entity\User")
 * @UniqueEntity(fields={"userPhone": "phoneNumber"}, entityClass="AppBundle\Entity\Phone", em="custom")
 */
class RegisterDTO
{
    /** @var string */
    private $userEmail;

    /** @var string */
    private $userPhone;
    
    //...
}

That's probably not enough. You also need to consider a way to determine whether or not a possible result is the object currently being modified (the current implementation checks for the object being returned to be the same as the one being validated).

Please also note that validating unique fields might still trigger the case I've listed before, so you'll need to add that either way. If so, you might just as well omit the validation imo, saves you a lot of work.

While this is not properly supported in core, one may consider using custom constraints to do so (example https://github.com/EnMarche/en-marche.fr/blob/master/src/Validator/UniqueMembershipValidator.php).

Here's more generic solution we are using https://gist.github.com/ostrolucky/7b4a7133e51f6b5ffcb598a287acb5f7

Also, can we give this issue more appropriate title please?

Another possible solution: https://gist.github.com/Xymanek/369f468d02069090770a1e4626d9f1e9

I can make a PR if it looks good

@iltar I'm unsure how your proposed solution would work. Or maybe I'm confused. But at the point of calling $this->em->flush(); the form should be in a submitted and valid state.

How would you then add errors to a field of an already submitted form?

While it may not display the errors in the WDT, the error will still be shown when you render the form.

But at the point of calling $this->em->flush(); the form should be in a submitted and valid state.

This is true. However, 1ms after the form was valid (it was unique at the moment of validation) and after that moment, someone else just flushed their entity with the exact same value, your flush will now fail with a UniqueConstraintException.

Wondering if this could be worked out (or worked-around) on Doctrine side.

Wouldn't it make sense to configure/extend from Doctrine Bridge to make it aware that a DTO corresponds to a specific Entity?

This way the UniqueEntity constraints would work transparently and wouldn't need to care if the variable is an actual Entity or a representation of that (DTO).

I just encountered the same issue and it should definitely be fixed as using a DTO is just cleaner than using the entity directly, especially with multiple APIs and possible necessary transformations.

Would be great if it would make it into 5.4

And the PR above #38662 seems to address and fix this issue already, it even takes possible property / field mappings into account, would be nice if it is merged or, if necessary, adjusted and merged so it can make it into 5.4 and 6.0

Resurrecting that issue; i just came across this need today myself.

Having the ability to call UniqueEntity constraint from outisde an entity would be the perfect answer.
Especially at the time of writing with ApiPlatform and their DTO implementation.

I'm totally for it too :

class RegistrationInput {

  public static function loadValidatorMetadata(ClassMetadata $metadata)
  {
        $metadata->addConstraint(new UniqueEntity([
            'entityClass' => User::class,
            'fields' => ['email']
        ]));
  }

}
// sorry - i'm not keen on annotations ^^

And by doing an assoc array we could eventually indicate the input value to field mapping :

$metadata->addConstraint(new UniqueEntity([
   'entityClass' => User::class,
   'fields' => ['email' => 'username']
]));

Reading the error message, it sounds like the usage of UniqueEntity is being unnecessary restricted to within an entity.

Unable to find the object manager associated with an entity of class "App\DataTransfer\RegistrationInput."

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

Personally I still think this is quite an important feature.

I made my own like this. Not perfect, but it works fine so far.

class UniqueDTO extends Constraint
{
    public ?string $atPath = null;
    public string $entityClass;
    public string|array $fields;
    public string $message = 'error.duplicate';

    public function getTargets(): string
    {
        return parent::CLASS_CONSTRAINT;
    }
}

class UniqueDTOValidator extends ConstraintValidator
{
    private EntityManagerInterface $em;
    private PropertyAccessorInterface $accessor;

    public function __construct(EntityManagerInterface $em, PropertyAccessorInterface $accessor)
    {
        $this->em = $em;
        $this->accessor = $accessor;
    }

    public function validate($value, Constraint $constraint): void
    {
        if (!$constraint instanceof UniqueDTO) {
            throw new UnexpectedTypeException($constraint, UniqueDTO::class);
        }

        if(!$constraint->entityClass) {
            throw new InvalidArgumentException('Entity class is required.');
        }

        $repository = $this->em->getRepository($constraint->entityClass);

        $fields = (array) $constraint->fields;
        $criteria = [];

        foreach ($fields as $from => $to) {
            $criteria[$to] = $this->accessor->getValue($value, $from);
        }

        if ($repository->count($criteria)) {
            $cvb = $this->context->buildViolation($constraint->message);

            if ($constraint->atPath) {
                $cvb->atPath($constraint->atPath);
            }

            $cvb->addViolation();
        }
    }
}

$metadata->addConstraint(new UniqueDTO([
    'atPath' => 'email',
    'entityClass' => User::class,
    'fields' => ['email' => 'email'],
    'message' => 'email.duplicate',
]));

Cheers

Another good solution for validate DTO's on unique field here

Hello @nickicool,

This won't work if you intend to make an update of your entity.

It's pretty odd the entityClass is not used to fetch the correct entity manager etc.

As for my solution, I decorated the standard UniqueEntityValidator, and when my decorator detects the $value to be one of my DTOs, I apply custom logic; otherwise, I pass it on to the standard validator:

<?php

namespace App\Validator\Constraint;

use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntityValidator as SymfonyUniqueEntityValidator;
// ... other imports, trimmed for brevity

#[AsDecorator('doctrine.orm.validator.unique')]
class UniqueEntityValidator extends ConstraintValidator
{
    public function __construct(
        private readonly EntityManagerInterface $entityManager,
        #[MapDecorated] private readonly SymfonyUniqueEntityValidator $inner
    ) {}

    public function validate($value, Constraint $constraint): void
    {
        if (!$value instanceof CrudDtoInterface) {
            $this->inner->validate($value, $constraint);

            return;
        }

        // Custom validation logic here. Part of my CrudDtoInterface is a method `belogsTo()` that returns FQCN of the Doctrine entity the DTO works with. Fetching the EM & checking for uniqueness is a simple use of `->findOneBy(...)`
    }
}

I looked at the stock validator, and the way it mingles $value::class and $constraint->entityClass doesn't make much sense. Does anyone know why $constraint->entityClass is not used exclusively when provided?