Returning a boolean wouldn’t work for updates since you wouldn’t know if your method returns true because of the entity you’re updating (in which case everything is fine) or another (in which case there is a violation).

Yes I know. Of course this would require some thought.
For example

$result = $repository->{$constraint->repositoryMethod}(...$arguments);
If repositoryMethod !== 'findBy' , then for example

$result = $repository->{$constraint->repositoryMethod}(...$arguments, $value);

For example, when $value is entity object and identifierFieldNames is 'id':

public function findMethod(array $criteria, object $value): bool
{
        $entity = $this->createQueryBuilder('o')
             ->select('count(o.id)');
            ->andWhere('o.alias = :alias')
            ->andWhere('o.id != :pk')
            ->setParameter('alias', $criteria['alias'])
            ->setParameter('pk', $value->getId())
            ->getQuery()
            ->getOneOrNullResult()
        ;

        /** @var int $count */
        $count = $qb->getQuery()->getSingleScalarResult();

        return $count > 0;
}

This is only example.
I need to figure out how to pass either the object I'm testing or the values ​​and keys for identifierFieldNames to the method from the repositoryMethod parameter and then insert that into the SQL query. So that I can eliminate the fact that when it comes to updates, I find the correct data. And I can then make a decision based on the boolean value.

In this example above, just a COUNT(id) SQL query is enough, instead of SELECT *. It seemed more optimal to me. But this validator doesn't allow this. If it makes sense, I'd be happy to try a pull request. ;-)
Thank you very much.

For example, when $value is entity object and identifierFieldNames is 'id':

If $value is an entity object, you don't need to use the identifierFieldNames option. Doctrine knows by itself what the identifier is in such a case. This option is required only during updates when $value is not an entity.

Is hydration really that costly? If the entities are too large, it's probably because the database was poorly designed or Doctrine shouldn't be used in that part of the code.

This solution would only make sense when adding new records. It’s enough to create a method like the one you created and then return something or nothing. However, I don’t think it requires additional code. Anyone who has performance issues can define such a method in the repository and provide its name.

Hi, it probably doesn't matter if it's a Doctrine entity or not. But I understand that identifierFieldNames is only specified if it's not a Doctrine entity. My mistake for writing it that way.

My idea comes from real usage. For example, we have it over an entity where there is a Uuid and 8x scalar column + one OneToOne relation.

It's nothing major. But I still think that the classic SELECT * + hydration will be a little less efficient than COUNT(*).

But yes, maybe that's an unnecessary hammer to a mosquito.
Of course, nothing prevents me from writing something of my own... UniqueEntityCallback validator and passing original data according to which I can find duplicates in the DB. Some parts will be identical to the UniqueEntity validator, but that doesn't matter. The logic will be to pass the name of the callback method in the appropriate repository, which will be passed as a class-string, just like in the case of UniqueEntity.
The idea was to have it all "under one roof" and of course contribute to open source ;-)