Won't it be a BC break as this behavior is thecurrent one described in other PRs, whereas the existing behavior until now matches thereal one ?

Well, the way I see it, it would be a BC break if the previously correct behavior was changed. But since thecurrent behavior is a bug, it is erroneous, so fixing it wouldn't be a BC break.

@lemoinem : I've thought about edges cases with this proposal: What if theUniqueEntityConstraint is declared on a parent class, which is not an entity, and thus, does not have a repository ?
This is the case of theFOSUserBundle for instance.

Indeed, that's a very good point... I didn't consider it because having a@UniqueEntity on a non-Entity class seems to be a non-sense to me... BTW, what you describe seems to be FOSUB 1 behavior only, FOSUB 2 definesFOS\UserBundle\Model\User as its entity and it's also the class the entity mapping is defined for.

However, that would definitely be a BC Break...

I'm thinking the best way would be to grab the highest parent of the current entity, among the descendants of the target that IS an Entity and use ITS Repository.

By this, I mean, given these classes:

Root (@Entity)| - Base (@UniqueEntity)    | - BaseEntity (@Entity)    |   | - ChildEntity (@Entity)    |       | - MyEntity (@Entity)    | - EntityB (@Entity)    | - EntityC (@Entity)

calling the validator on an instance ofMyEntity would use the Repository ofBaseEntity. This is consistent with the strategy of using the highest possible Repository with respect to the target.

Using the Repository ofRoot could enforce the constraint against values that aren't supposed to be included (i.e. matching against Entities that aren't instances ofBaseEntity).

Trying to compute the exact match (i.e. trying to lookup in the Repositories ofBaseEntity,EntityB andEntityC), while being semantically correct (we match against ALL the entities instance ofBase) seems to be as being highly unreliable since it will depend on which classes have a mapping loaded at the time the Constraint is validated. This could be far from complete and volatile in the case of Annotations Mappings.

FOSUB 2 defines FOS\UserBundle\Model\User as its entity and it's also the class the entity mapping is defined for.

I don't see what you mean. The file I linked above is from the master branch and so is FOSUser 2. :/
The mapping is, indeed, on theFOS\UserBundle\Model\User, as well as the validation constraints, but this class is still abstract and you'll need to extend it. So when calling the validator on your own user, the target will beFOS\UserBundle\Model\User, but this class isn't an entity (just a mapped superclass) and doesn't have a repository.

Your new suggestion seems good to me however.

I was referring toFriendsOfSymfony/FOSUserBundle@047b0e6 which deleted the Entity classes.

Since this commit, inmaster, theDoctrine mapping is now applied onFOS\UserBundle\Model\User instead ofFOS\UserBundle\Entity\User previously. However I just saw it's not an Entity mapping but a Mapped Superclass mapping. So you were right, my bad.

However, having aUniqueEntity constraint on a Mapped Superclass makes more sense than on a class without any kind of mapping. I'm guessing we could deprecate applyingUniqueEntity on a class without mapping. I'm thinking it would be a separate issue, and I'm not sure either whether that could help with the process of discovering the right Repository to use. I'll check during the implementation if it does.

Thank you for the feedback!

After testing (https://github.com/lemoinem/symfony-standard/tree/test/doctrine/mapped-superclass-repository,composer install, Setup DB,bin/console doc:sc:up --force, Insert various Entities (discr may be either "root" or "entity",bin/console test), calling a MappedSuperclass' Repository is perfectly fine, as long as there is a parent entity and the fields the query is based on are defined and mapped and such parent entity.Doctrine documentation does specify that MSC aren't supposed to be query-able.

This doesn't change much to the implementation I intended to put in place.

OK, I finally had time to write a relevant test case for the repository search.
I used the "highest repository" strategy we discussed. If you have any other feedback, I'd be happy to hear it!

PS: I also took the chance to rebase both PRs. The PHP 5.6 Travis build currently fails because of FrameworkBundle errors which aren't related to this PR.