Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.6k
[Doctrine] [Bridge] Add a "repository" option to the uniqueEntity validator#12977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
I define my Repositories as service, would I be able to somehow define a service for this as well? I think that would complete this feature. |
| @@ -113,7 +113,27 @@ public function validate($entity, Constraint $constraint) | |||
| } | |||
| } | |||
| $repository = $em->getRepository(get_class($entity)); | |||
| if(null != $constraint->repository) { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
null !== $constraint->repository
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Thanks 👍
Any news about this ? A single test was added. @iltar : When working with repositories as services, I guess you use something similar tothis gist ? Or do you create your repositories without using the factory ? |
@ogizanagi What it basically comes down to is this: services:app.user.repository:class:App\Repository\UserRepositoryfactory:[@doctrine.orm.entity_manager, getRepository]arguments: -App:User |
@iltar : Then the entityManager and factory will be able to retrieve the repository through the entity class name. I don't think there is any benefit specifying the repository service id in the |
@iltar the repository retrieved from the EntityManager will still be the same instance than the one in your container. Btw, be careful when registering your repositories as services: it means you cannot use |
…idatorThe 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.
Fixessymfony#16969Fixessymfony#4087Fixessymfony#12573Incompatible withsymfony#15002Incompatible withsymfony#12977
Fixessymfony#16969Fixessymfony#4087Fixessymfony#12573Incompatible withsymfony#15002Incompatible withsymfony#12977
Fixessymfony#16969Fixessymfony#4087Fixessymfony#12573Incompatible withsymfony#15002Incompatible withsymfony#12977
Fixessymfony#16969Fixessymfony#4087Fixessymfony#12573Incompatible withsymfony#15002Incompatible withsymfony#12977
Fixessymfony#16969Fixessymfony#4087Fixessymfony#12573Incompatible withsymfony#15002Incompatible withsymfony#12977
Fixessymfony#16969Fixessymfony#4087Fixessymfony#12573Incompatible withsymfony#15002Incompatible withsymfony#12977
Fixessymfony#16969Fixessymfony#4087Fixessymfony#12573Incompatible withsymfony#15002Incompatible withsymfony#12977
Fixessymfony#16969Fixessymfony#4087Fixessymfony#12573Incompatible withsymfony#15002Incompatible withsymfony#12977
…ed by the UniqueEntity validator (ogizanagi)This PR was merged into the 3.2-dev branch.Discussion----------[DoctrineBridge] Add a way to select the repository used by the UniqueEntity validator| Q | A| ------------- | ---| Bug fix? | no| New feature? | yes| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets |#12573,#4087,#12977| License | MIT| Doc PR |symfony/symfony-docs#7057This is a cherry pick of#12977 on ~~2.8~~ 3.2 branch, as it is clearly a new feature, even if it was primary introduced in order to fix an inappropriate behavior that might be considered as a bug.Commits-------00d5459 [Doctrine] [Bridge] Add a way to select the repository used by the UniqueEntity validator
See#12573 for more explanations.
I made a pull request for the 2.7 branch, as pragmatically, this is a new feature. But IMO, it's questionable, as it is an easy-pick for older branches and solves what might be considered as a bug, or at least induces one. This could easily be merged into 2.3 without any bad behavior.
The new repository option expects an entity path, in order to select its repository.
This allows to use properly the
UniqueEntityconstraint on hierarchical (inheritance) entities, using the root class repository in order to check the uniqueness, and not just the child repository.Given this inheritance scheme:
The code below is now sufficient in order order to check username uniqueness in both
Customer&Societyentities, when trying to register aCustomer.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
currentvalue for therepositoryoption, auto-detecting the class on which the constraint is bound. (feasible ??)Some other values could be considered 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:
repositoryoption name is disputable, as it expects an entity path in order to load its repository, and not the repository itself. Should it be renamed ?