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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Doctrine] [Bridge] Add a "repository" option to the uniqueEntity validator #12573
Comments
lemoinem
added a commit
to lemoinem/symfony
that referenced
this issue
Dec 11, 2015
Fixes symfony#16969 Fixes symfony#4087 Fixes symfony#12573 Incompatible with symfony#15002 Incompatible with symfony#12977
1 task
lemoinem
added a commit
to lemoinem/symfony
that referenced
this issue
Dec 12, 2015
Fixes symfony#16969 Fixes symfony#4087 Fixes symfony#12573 Incompatible with symfony#15002 Incompatible with symfony#12977
lemoinem
added a commit
to lemoinem/symfony
that referenced
this issue
Dec 16, 2015
Fixes symfony#16969 Fixes symfony#4087 Fixes symfony#12573 Incompatible with symfony#15002 Incompatible with symfony#12977
lemoinem
added a commit
to lemoinem/symfony
that referenced
this issue
Feb 2, 2016
Fixes symfony#16969 Fixes symfony#4087 Fixes symfony#12573 Incompatible with symfony#15002 Incompatible with symfony#12977
lemoinem
added a commit
to lemoinem/symfony
that referenced
this issue
Feb 2, 2016
Fixes symfony#16969 Fixes symfony#4087 Fixes symfony#12573 Incompatible with symfony#15002 Incompatible with symfony#12977
lemoinem
added a commit
to lemoinem/symfony
that referenced
this issue
Feb 2, 2016
Fixes symfony#16969 Fixes symfony#4087 Fixes symfony#12573 Incompatible with symfony#15002 Incompatible with symfony#12977
lemoinem
added a commit
to lemoinem/symfony
that referenced
this issue
Feb 2, 2016
Fixes symfony#16969 Fixes symfony#4087 Fixes symfony#12573 Incompatible with symfony#15002 Incompatible with symfony#12977
lemoinem
added a commit
to lemoinem/symfony
that referenced
this issue
Feb 3, 2016
Fixes symfony#16969 Fixes symfony#4087 Fixes symfony#12573 Incompatible with symfony#15002 Incompatible with symfony#12977
fabpot
added a commit
that referenced
this issue
Oct 14, 2016
…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#7057 This 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related to #4087
I encountered kind of the same issue today.
Here is the inheritance scheme of my use case:
The
BaseUser
, handled byFOSUserBundle
, defines anUniqueEntity
constraint on bothemailCanonical
andusernameCanonical
fields. But this constraint use the entity repository depending of the real child type of the user I want to register (i.eCustomerRepository
when trying to register a newCustomer
).Therefore, trying to register a new
Customer
with the same email or username as aSociety
will not fail the validation, but fails at database level.Given the fact that a new
repositoryMethod
option was added in #4979, an easy workaround is to create a dedicated method in both Customer and Society repositories, calling internally theUserRepository
, as for example:and use it in
UniqueEntity
constraint definition in both entities :Although it works, this induces useless code duplication (beside the fact that the FOSUser defined constraints are useless, but triggered, because we cannot overload the
validation/orm.xml
. But that is another story :) )I certainly could have define the
UniqueEntity
constraint into my ownUser
class. But then, when adding a new user type, I must not forget to create thefindByInRootUser
method into the new repository (or create a repository class to extend).Here comes my suggestion:
Add a
repository
option to theUniqueEntity
validator.This will ensure the proper repository will be used by the constraint, and I could define it only at the
User
entity level:If a value for the
repository
option isn't provided, the behavior remains the same: TheUniqueConstraintValidator
will get the repository from the real class at runtime.Do you see any issue with that approach ?
I'm not sure of the component ability to guess the class on which the constraint was defined, but if it is possible, it could not be considered, because of the BC promise. That's why a suggested another approach.
Maybe for the 3.0 ? But it might lead to more unwanted behaviors than benefits.
The text was updated successfully, but these errors were encountered: