When a Symfony DTO property and its Doctrine entity field use different names, UniqueEntity accepts a mapping in fields. Set errorPath to the DTO property explicitly so the violation is attached to the field your form or API actually exposes.
Last updated: November 14, 2026.
<?php
namespace AppDto;
use AppEntityUser;
use SymfonyBridgeDoctrineValidatorConstraintsUniqueEntity;
use SymfonyComponentValidatorConstraints as Assert;
#[UniqueEntity(
entityClass: User::class,
fields: ['userIdentifier' => 'email'],
errorPath: 'userIdentifier',
message: 'An account already uses this email address.',
)]
final class RegistrationInput
{
#[AssertNotBlank]
#[AssertEmail]
public ?string $userIdentifier = null;
}The mapping reads the DTO property userIdentifier and compares it with the entity field email. The error path remains the DTO property name.
Separate lookup mapping from presentation
The Symfony UniqueEntity documentation permits a key-value mapping when the validated object is not a managed entity: the key is the object property and the value is the entity property. This tells Doctrine which value to query, but the validation violation still needs a property path meaningful to the DTO consumer.
The documented default for errorPath is the first field in fields. With mapped fields and behavior that varies by release, relying on that default can bind the message to the entity-side name. An explicit DTO-side path is clearer and stable for forms, serializers, and problem-detail responses.
Keep database uniqueness authoritative
UniqueEntity provides a useful early validation message, but it cannot prevent a race between validation and insertion. Keep a unique index or constraint on the database column and handle the duplicate-key exception at the write boundary.
Add a validation test that submits an existing email and asserts both the message and exact property path. Also test a new address and a malformed address. The issue that prompted this guidance discusses mapped fields in Symfony 7.1 and later; setting errorPath explicitly avoids depending on a future change to the default while preserving the documented mapping.
