Symfony : créer des entités à partir d'une BDD

Pour un projet Symfony, si le client vous fournit une base de données, pas de panique : Symfony propose tout le nécessaire pour une gestion intuitive et efficace.

a marqué ce sujet comme résolu.

Tout le monde se secoue ! :D

Dwaps a commencé (mardi 18 avril 2017 à 11h54) la rédaction d’un tutoriel au doux nom de « Symfony : créer des entités à partir d’une BDD » et nous avons pour objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limites pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !

+0 -0

Salut !

J’ai parcouru avec attention votre tutoriel, et voici mes retours.

Après avoir fait les diagrammes de classe‌s‌ en UML‌, il est facile de générer toutes les entités nécessaires en ligne de commande. Le chemin inverse est tout aussi facile. C’est exactement ce que je vous propose de voir ici.

Le chemin inverse de "générer toutes les entités [depuis le diagramme UML]", c’est de créer le diagramme de classes UML depuis les entités, à mon sens, mais je ne crois pas que ce soit ce que vous faites ni ce que vous voulez dire.
Et ne pas confondre une représentation des tables avec un diagramme de classes UML, ce n’est pas la même chose (il suffit de penser aux tables intermédiaires dans les ManyToMany).

Nous ne créerons pas l’interface utilisateur dans ce tutoriel. Ici, nous ne travaillerons que la BDD.

Oui et non, les entités ne sont pas la BDD, même si elles y sont fortement liées il est vrai. Je pense qu’il faudrait reformuler ça, l’idée étant que Symfony est un framework MVC, on va ici s’occuper que de la partie M[odèle].

Voici sans tarder le code SQL que je vous propose :

Je le relève dans cette phrase, mais vous êtes deux auteurs, ça fait donc bizarre de voir un "je".

Génération d’un bundle pour la gestion modèle

[…] la gestion des modèles

Pour la partie "Création des entités depuis la BDD", je suis relativement surpris.

Dans l’ordre, vous :

  1. donnez la commande pour exporter directement au format annotation ;
  2. parlez des autres formats qui nécessitent l’utilisation de doctrine:generate:entities comme "une étape supplémentaire"…
  3. … étape que vous devez ensuite utiliser quand vous voyez que les entités générées avec annotations n’ont pas les getters et setters…
  4. … en repassant par un autre format de mapping.

Bref, j’espère que vous comprenez à quel point j’ai voulu vous rendre service…

Non.
Donnez directement la marche à suivre correcte et efficace, puis expliquez le cas particulier, ce sera plus simple et compréhensible à mon avis.

Je suis aussi surpris qu’il faille passer par un autre format quand on souhaite avoir les entités sous forme d’annotations. Est-ce que c’est vraiment nécessaire ? Est-ce que ce n’est pas simplement un souci de cache qui fait que les entités ne sont pas immédiatement reconnues ? Dans ce cas, pourquoi ne pas simplement utiliser un cache:clear ?

Dernier point : il n’est actuellement pas fait mention que certaines relations "complexes" pourront ne pas être reconnues correctement, ni que (du moins dans mon souvenir datant de Doctrine 2.4) les relations ne sont pas automatiquement bi-directionnelles, et donc demandent une reprise "manuelle" des entités et le cas échéant des mappings. Je pense qu’il est nécessaire de préciser que cela fournit des entités "de base" dans des cas simples, mais qu’il faut bien faire attention avant de se reposer sur ce qui a été généré de cette manière.

+0 -0

Alors, je retiens tes propositions, mais il y en a une qui m’embête.

Je le relève dans cette phrase, mais vous êtes deux auteurs, ça fait donc bizarre de voir un "je".

Ymox

Alors, en fait, je ne suis que le correcteur, comme c’est Dwaps qui a tout écrit, j’ai laissé les "je". Il faut peut-être que l’on soit plus clairs sur ce point, ou alors que l’on remplace les "je" par des "nous", mais je n’apprécie pas cette solution car elle ferait que je m’approprierais le travail de quelqu’un d’autre.

De plus, pour celles qui concernent trop le fonds du propos, je ne suis pas l’auteur, et donc ce n’est pas moi qui décide…

+0 -0

Alors, en fait, je ne suis que le correcteur, comme c’est Dwaps qui a tout écrit, j’ai laissé les "je". Il faut peut-être que l’on soit plus clairs sur ce point, ou alors que l’on remplace les "je" par des "nous", mais je n’apprécie pas cette solution car elle ferait que je m’approprierais le travail de quelqu’un d’autre.

amael

Je m’en doutais, mais effectivement sans précision, ça ne me paraissait pas clair. Soit le rôle de chacun est à préciser, soit seul le "véritable" auteur reste l’auteur du tutoriel.

Si j’ai bien compris, la mise à jour ne concerne que les corrections orthographiques/syntaxiques/grammaticales ?

+0 -0

Salut Ymox,

Et ne pas confondre une représentation des tables avec un diagramme de classes UML, ce n’est pas la même chose (il suffit de penser aux tables intermédiaires dans les ManyToMany). – [Ymox]

Il est évident qu’un diagramme UML n’est pas une représentation des tables de la BDD. Et par rapport à mon tuto, je pousse un grand OUPS sur mon intro : je viens de la relire et je me rends compte que je l’ai écrite trop vite. En effet, elle ne rends pas compte de l’objectif du tutoriel ni du titre d’ailleurs puisqu’il s’agit de présenter la procédure BDD –> entities dans l’essentiel. Alors merci Ymox pour ta remarque : je vais reformuler mon intro.

…les entités ne sont pas la BDD, même si elles y sont fortement liées il est vrai. Je pense qu’il faudrait reformuler ça… – [Ymox]

Je comprends l’amalgame qui peut être fait. Mon excuse est la même que précédemment : ce tuto est en cours et je n’ai encore eu le temps de l’affiner, et du coup : merci d’avoir pris le temps de me relire ! Il est tout aussi évident que les entités ne sont PAS la BDD pour reprendre tes propos (plus précisément les tables de la BDD). En écrivant cela, j’avais en tête l’objet général du cours…

Dans l’ordre, vous : 1. donnez la commande pour exporter directement au format annotation ; 2. parlez des autres formats qui nécessitent l’utilisation de doctrine:generate:entities comme "une étape supplémentaire"… 3. … étape que vous devez ensuite utiliser quand vous voyez que les entités générées avec annotations n’ont pas les getters et setters… 4. … en repassant par un autre format de mapping. – [Ymox]

Oui, je donne la commande pour exporter directement en annotation, tu as bien lu ! Dans mon désir d’aller pas à pas, j’ai voulu exposer une seule commande. C’est pour cette raison que les autres sont données NON comme une étape supplémentaire comme tu le penses mais dans un aparté. Cela signifie que celles-ci sont présentées comme autres alternatives possibles (chaque format présentant ses propres avantages et inconvénients). Et en passant même si j’apporte une appréciation personnelle sur le XML, cela ne signifie pas pour autant que je le considère inutile, car dans bien des cas ce format rend bien des services, et dans le contexte Symfony ce n’est pas pour rien que beaucoup des bundles populaires en font usage !

Je suis aussi surpris qu’il faille passer par un autre format quand on souhaite avoir les entités sous forme d’annotations – [Ymox]

??? J’ai dit ça moi ? Je prendrai le temps de bien me relire…

Donnez directement la marche à suivre correcte et efficace, puis expliquez le cas particulier. – [Ymox]

Bon là, il s’agit d’un problème d’appréciation personnelle sur la structuration du tuto. Je suis disposé à changer ça mais je ne pourrais pas le faire rapidement malheureusement. Du coup, si tu veux apporter ta contribution n’hésites pas à me demander de t’ajouter comme co-auteur, j’en serais ravi. De cette façon, tu pourrais mentionner également le complément sur les relations complexes. ;)

Pas de soucis non plus pour le côté "nous" : à partir du moment où quelqu’un fait des modifications, il est tout à fait normal de ré-adapter. L’important étant que le "nous" soit légitime, c’est tout. Donc, sens-toi libre, tu as mon feu vert !

+0 -0

Merci de ton retour  :)

Je suis aussi surpris qu’il faille passer par un autre format quand on souhaite avoir les entités sous forme d’annotations — [Ymox]

???
J’ai dit ça moi ? Je prendrai le temps de bien me relire…

dwaps

Pas directement : on peut bien avoir les entités avec les annotations, mais il faut passer par un autre format pour générer les accesseurs et mutateurs. Du coup, je reviens avec ma question : pourquoi est-ce nécessaire ? Soucis de cache, ou il n’y a vraiment pas d’autre moyen ? Et du coup, pourquoi ne pas directement faire passer par un autre format, puis supprimer les mappings qui risquent de poser problème par la suite ?
Parce qu’imaginons Kévin (prononcer dans ce cas précis "quai 20") a ainsi généré ses entités avec les annotations, est passé par le XML pour pouvoir générer les mutateurs et accesseurs, puis souhaite ajouter quelque chose. Comme il a les annotations, il va ajouter avec les annotations. Mais il n’a pas supprimé les mappings XML qui priment sur les annotations…
Question subsidiaire : quand on ajoute ainsi une propriété avec annotations dans une entité (et qu’on n’a bien que des annotations pour les mappings), comment fait-on pour générer les méthodes get* et set*, on passe aussi par un autre format ? Si oui, pourquoi utiliser les annotations, alors ? Et si non, on en revient à ma question initiale…

Edit

OK, même dans la documentation officielle de Symfony ils disent qu’il faut passer par un format intermédiaire. Notons au passage qu’ils font comme je le proposais, à savoir convertir d’abord en (X|YA)ml|PHP, et ensuite convertissent en annotations.

A noter aussi que, vu la documentation, il est difficile de voir la valeur ajoutée de ton tutoriel par rapport à elle.

+0 -0

Merci pour ce petit retour, cher Ymox. :) Je vois bien que tu es un passionné, c’est très bien.

Moi j’aurais prononcer Kévin de cette façon : ’Kévinne’, mais bon chacun est libre après tout.

Une chose à savoir : un tutoriel n’est pas forcément fait pour ajouter une valeur à la doc, il peut aussi rendre plus accessible cette dernière sans pour autant être aussi exhaustif (ce qui serait plutôt prétentieux, tu ne penses pas ?). En d’autres termes, cela signifie qu’il y aura toujours des subtilités à soulever quant à l’élaboration d’un tutoriel, et il pourra toujours être améliorer. Je te remercie pour ta contribution mais pourquoi, justement, ne te proposes-tu pas comme co-auteur si tu penses être en mesure d’apporter une valeur ajoutée à cette ébauche ? J’en serais ravi car, comme je te l’ai dis, je ne pourrais pas bosser dessus en ce moment malheureusement. Tu pourrais aussi rajouter un lien vers la documentation ? (Une idée, comme ça).

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte