[Validator] Improve documentation for UniqueEntity constraint
#21197
Conversation
carsonbot
changed the title
ker0x
force-pushed
the
fix/unique-entity
branch
2 times, most recently
from
604f8fe to
b1a3e1a
Compare
OskarStark
changed the title
UniqueEntity constraint
| This constraint can also check **uniqueness on any PHP class** and not only on | ||
| Doctrine entities. Consider the following Doctrine entity:: |
There was a problem hiding this comment.
The phrase "any PHP class" implies that the constraint can be applied to any arbitrary PHP class, regardless of its relationship to Doctrine.
| This constraint can also check **uniqueness on any PHP class** and not only on | |
| Doctrine entities. Consider the following Doctrine entity:: | |
| This constraint can also check **uniqueness on any PHP class** that is mapped to a Doctrine entity, and not only on the entities themselves. Consider the following Doctrine entity:: |
| @@ -103,29 +100,6 @@ between all of the rows in your user table: | |||
| } | |||
| } | |||
| // src/Form/Type/UserType.php | |||
| namespace App\Form\Type; | |||
| )] | ||
| class UserDto | ||
| { | ||
| public ?int $id = null, |
There was a problem hiding this comment.
I would remove the id parameter. It might be misleading and suggest that an identifier is required, just like in an entity. Additionally, someone might assume that during an update, the validator would automatically match this class to the corresponding entity based on the id—as it currently works with Doctrine entities.
Update without identifierFieldNames will not work.
| @@ -269,9 +353,97 @@ the combination value is unique (e.g. two users could have the same email, | |||
| as long as they don't have the same name also). | |||
|
|
|||
| If you need to require two fields to be individually unique (e.g. a unique | |||
| ``email`` and a unique ``username``), you use two ``UniqueEntity`` entries, | |||
| ``email`` and a unique ``username``), you should use two ``UniqueEntity`` entries, | |||
There was a problem hiding this comment.
Should is more like a suggestion, but there is no choice here. You must use it that way, if you require it.
|
|
||
| **type**: ``array`` **default**: ``[]`` | ||
|
|
||
| The ``identifierFieldNames`` option allows you to specify the field |
There was a problem hiding this comment.
I've noticed that some people define this parameter even when working with entities. However, entities automatically know which property is the identifier. It would be worth adding a note that in such cases, there's no need to define identifierFieldNames.
Additionally, it's only required during updates.
Replace #14458 and #20166
I'm targeting
7.3because i don't know if changes made in7.1are transferred to 7.3. Otherwise, let me know and I'll change it.