Description
| Q | A |
|---|---|
| Bug report? | yes/no |
| Feature request? | no |
| BC Break report? | yes/no |
| RFC? | yes |
| Symfony version | 3.2.0 |
I wonder how this should work for very common example using DTOs for forms. I have applied validation to my DTO
AppBundle\Command\Register:
constraints:
- Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity:
fields: email
entityClass: AppBundle\Entity\User
em: default
With this configuration I get error: "The class 'AppBundle\Command\Register' was not found in the chain configured namespaces AppBundle\Entity"
The flow currently works like this I set em for my entity: AppBundle\Entity\User but in validator we have getting current class metadata for main entity (in my example AppBundle\Command\Register this is not an entity) $em->getClassMetadata(get_class($entity)); so this is why it fails.
# Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntityValidator
if ($constraint->em) {
$em = $this->registry->getManager($constraint->em);
if (!$em) {
throw new ConstraintDefinitionException(sprintf('Object manager "%s" does not exist.', $constraint->em));
}
} else {
$em = $this->registry->getManagerForClass(get_class($entity));
if (!$em) {
throw new ConstraintDefinitionException(sprintf('Unable to find the object manager associated with an entity of class "%s".', get_class($entity)));
}
}
$class = $em->getClassMetadata(get_class($entity));
/* @var $class \Doctrine\Common\Persistence\Mapping\ClassMetadata */
IMHO if we specify entityClass we should expect that everything will concern this entityClass. Another example of failure is when two entities: entity1 and entity2 belong to different entity managers. If this is an expected behaviour (IMHO it should work like this) we should at least add this information to documentation ?