Les réponses ci-dessus n'étaient pas suffisantes pour que je comprenne ce qui se passait, donc après y avoir approfondi davantage, je pense que j'ai un moyen de l'expliquer qui aura du sens pour les personnes qui ont lutté comme moi pour comprendre.
inversedBy et mappedBy sont utilisés par le moteur INTERNAL DOCTRINE pour réduire le nombre de requêtes SQL qu'il doit effectuer pour obtenir les informations dont vous avez besoin. Pour être clair si vous n'ajoutez pas inversedBy ou mappedBy, votre code fonctionnera toujours mais ne sera pas optimisé .
Par exemple, regardez les classes ci-dessous:
class Task
{
/**
* @var int
*
* @ORM\Column(name="id", type="integer")
* @ORM\Id
* @ORM\GeneratedValue(strategy="AUTO")
*/
private $id;
/**
* @var string
*
* @ORM\Column(name="task", type="string", length=255)
*/
private $task;
/**
* @var \DateTime
*
* @ORM\Column(name="dueDate", type="datetime")
*/
private $dueDate;
/**
* @ORM\ManyToOne(targetEntity="Category", inversedBy="tasks", cascade={"persist"})
* @ORM\JoinColumn(name="category_id", referencedColumnName="id")
*/
protected $category;
}
class Category
{
/**
* @var int
*
* @ORM\Column(name="id", type="integer")
* @ORM\Id
* @ORM\GeneratedValue(strategy="AUTO")
*/
private $id;
/**
* @var string
*
* @ORM\Column(name="name", type="string", length=255)
*/
private $name;
/**
* @ORM\OneToMany(targetEntity="Task", mappedBy="category")
*/
protected $tasks;
}
Ces classes si vous exécutez la commande pour générer le schéma (par exemple bin/console doctrine:schema:update --force --dump-sql), vous remarquerez que la table Category ne contient pas de colonne pour les tâches. (c'est parce qu'il n'a pas d'annotation de colonne)
La chose importante à comprendre ici est que les tâches variables sont uniquement là pour que le moteur de doctrine interne puisse utiliser la référence au-dessus de lui qui indique sa catégorie mappedBy. Maintenant ... ne soyez pas confondu ici comme je l'étais ... La catégorie ne fait pas référence au nom de la classe, elle fait référence à la propriété de la classe Task appelée 'protected $ category'.
De même, dans la classe Tasks, la propriété $ category mentionne qu'elle est inversedBy = "tasks", notez que c'est au pluriel, ce n'est PAS LE PLURIEL DU NOM DE LA CLASSE , mais simplement parce que la propriété est appelée 'protected $ tasks' dans la catégorie classe.
Une fois que vous avez compris cela, il devient très facile de comprendre ce que font inversedBy et mappedBy et comment les utiliser dans cette situation.
Le côté qui fait référence à la clé étrangère comme `` tâches '' dans mon exemple obtient toujours l'attribut inversedBy car il a besoin de savoir quelle classe (via la commande targetEntity) et quelle variable (inversedBy =) sur cette classe pour `` travailler en arrière '' pour parler et obtenir les informations sur la catégorie. Un moyen facile de s'en souvenir est que la classe qui aurait le Foreignkey_id est celle qui doit avoir inversedBy.
Où, comme pour la catégorie et sa propriété $ tasks (qui n'est pas sur la table, rappelez-vous, seule une partie de la classe à des fins d'optimisation) est MappedBy `` tâches '', cela crée officiellement la relation entre les deux entités afin que la doctrine puisse maintenant en toute sécurité utilisez des instructions SQL JOIN au lieu de deux instructions SELECT séparées. Sans mappedBy, le moteur de doctrine ne saurait à partir de l'instruction JOIN qu'il créera quelle variable dans la classe 'Task' pour mettre les informations de catégorie.
J'espère que cela explique un peu mieux.