Symfony2 UniqueEntity plusieurs champs: faux positif de validation?

Je suis en train de valider l'unicité d'une entité soumise à partir d'un formulaire à l'aide de UniqueEntity Contrainte de Validation sur plusieurs champs.

Code de l'entité qui doit être unique a deux champs - fieldA et fieldB, à la fois unique:

/**
 * @ORM\Table(name="mytable")
 * @ORM\Entity
 * @DoctrineAssert\UniqueEntity(fields = {"fieldA", "fieldB"})
 */
class myClass
{
  /**
   * @ORM\Column(name="fieldA", type="string", length=128, unique=true)
   */
  protected $fieldA;

  /**
   * @ORM\Column(name="fieldB", type="string", length=128, unique=true)
   */
  protected $fieldB;
}

Supposons que j'ai déjà un enregistrement dans la base de données avec des valeurs:

  • fieldA = 'value_a', fieldB = 'value_b'

Maintenant, quand j'essaie d'en soumettre un autre avec des valeurs (fieldA = 'value_a', fieldB = 'value_c') à partir d'un formulaire, Symfony2 génère une requête pour vérifier l'unicité:

SELECT ... FROM ... WHERE fieldA = ? AND fieldB = ? ('value_a', 'value_c')

Et la validation passe, parce que le résultat est un ensemble vide, mais je m'attends à un échec, car fieldA de ne pas être la seule dans ce cas. (SQL insert échoue avec une entrée en double erreur sur "value_a'.)

Symfony2 est UniqueEntity documentation dit:

Cette option obligatoire est le champ (ou de la liste de champs) sur lequel cette entité doit être unique. Par exemple, vous pouvez spécifier que le courriel et le nom des champs dans de l'Utilisateur exemple ci-dessus doit être unique.

Je pense qu'il confirme mes attentes.

J'ai découvert dans la source de UniqueEntityValidator (ligne 94), le validateur prend les champs comme dans un tableau, et utilise le "findBy" magie méthode de recherche pour vérifier l'unicité. Cette méthode utilise " ET " relation entre les paramètres de la requête, ce qui provoque le problème.

Est-il possible d'utiliser cette contrainte de validation pour mon problème d'une certaine manière, ou je dois les valider par un autre chemin?

InformationsquelleAutor csabavegso | 2011-12-13
  1. 10

    Ce sujet :

    /**
 * @ORM\Table(name="mytable")
 * @ORM\Entity
 * @DoctrineAssert\UniqueEntity(fields = "fieldA")
 * @DoctrineAssert\UniqueEntity(fields = "fieldB")
 */
class myClass

    ?

    • Merci, il fait le travail! Le seul problème, c'est que chaque affirmer prend une autre question, mais je pense que je peux vivre avec ça.
    • Sinon, vous avez toujours la solution pour vous écrire propre programme de validation, avec l'inspiration de la UniqueEntity Validateur
    InformationsquelleAutor webda2l
  2. 16

    Il devrait être:

    /**
 * @ORM\Table(name="mytable")
 * @ORM\Entity
 * @DoctrineAssert\UniqueEntity(fields = "fieldA")
 * @DoctrineAssert\UniqueEntity(fields = "fieldB")
 */
class myClass

    En faisant

     * @DoctrineAssert\UniqueEntity(fields = {"fieldA", "fieldB"})

    il va vérifier si il n'y a pas toutes les lignes avec les deux champs de la même.

    Supposons donc que vous avez déjà un enregistrement dans la base de données avec des valeurs:

    fieldA = 'value_a', fieldB = 'value_b'

    Maintenant, quand vous essayez d'en soumettre un autre avec des valeurs (fieldA = 'value_a', fieldB = 'value_c') à partir d'un formulaire, Symfony2 génère une requête pour vérifier l'unicité:

    SELECT ... from ... OÙ fieldA = ? ET fieldB = ? ('value_a', 'value_c')

    et cela va passer, parce que ça ne correspond pas à une ligne avec 

    fieldA = 'value_a', fieldB = 'value_b'

    seulement quand yo soumettre un autre avec des valeurs (fieldA = 'value_a', fieldB = 'value_b') à partir d'un formulaire, la validation ne passera pas.

    C'est la façon dont il devrait fonctionner et comment il est expliqué dans la documentation:
    http://symfony.com/doc/current/reference/constraints/UniqueEntity.html#fields

    • mais sachez que Cette contrainte ne fournit pas de protection contre des conditions de course. Ils peuvent se produire si une autre entité est maintenu par un processus externe après cette validation a passé et avant cette entité est en fait persisté dans la base de données. comme mentionné dans le lien que vous fournissez.
    InformationsquelleAutor Jimmy Knoot