symfony/symfony — pull request #12977 by ogizanagi (2014-12-14 20:37:40+00:00)
Title: [Doctrine] [Bridge] Add a "repository" option to the uniqueEntity validator

| Q | A
| ------------- | ---
| Bug fix? | not really
| New feature? | yes, but debatable
| BC breaks? | no
| Deprecations? | no
| Tests pass? | No
| Fixed tickets | #12573, #4087
| License | MIT

I made a pull request for the 2.7 branch, as this is a new feature. But IMO, it's questionable, as it is an easy-pick for older branches. This could easily be merge into 2.3.

The new repository option expects an entity path, in order to select its repository.
This allows to use properly the `UniqueEntity` constraint on hierarchical (inheritance) entities, using the root class repository in order to check the uniqueness, and not just the child repository.

Given this scheme:

`User` ← `Customer`
.‪.…‪…‪ ← `Society`

The code below is now sufficient in order order to check username uniqueness in both `Customer` & `Society` entities, when trying to register a `Customer`.

```php
#ACME\UserBundle\Entity\User.php
/**
* @ORM\Entity
*
* @UniqueEntity(fields="username", repository="ACME\UserBundle\Entity\User")
*
*/
class User { ... }
```

Not specifiying the repository option will not cause any issue, and keep the same behavior as before.

## Further:

The above case, IMO, might be the most used one, and it seems perhaps redondant to specify the current class as the repository to use for the constraint. Maybe we could imagine a `current` value for the `repository` option, auto-detecting the class on which the constraint is bound. (feasible ??)

Some other values could be considred in this way:
- `current`: As described above, will detect the exact class on which the constraint was bound, and use its repository.
- `root`: Will search for the top-level entity (User) and automatically use its repository.
- `real`: the current behavior. Is the default value for the repository option (or null).

For 3.0, I think the default value should be `current`.

## Discuss:

- For now, the `repository` option name is disputable, as it expects an entity path in order to load its repository, and not the repository itself. Should it be renamed ?