Discussion :

[PeytaWodka]

Bonjour,

Dans le cadre de mon stage, on m'a demandé d'automatiser au maximum les opérations à effectuer pour générer un projet viable avec symfony et j'en suis arrivé à concevoir une classe qui, d'un schéma généré à partir d'une base de données, 'nettoie' celui-ci pour arriver à un modèle objet. Je conçois que ce n'est pas correct mais on m'a demandé de faire ça. Pour le moment, il fonctionne mais il nécessite de passer derrière pour donner du sens à certains noms de relation.
J'aimerai avoir vos avis sur cette démarche car j'ai besoin de recul sur celle-ci avant de le publier ou d'en parler dans mon rapport de stage ?

PS : je ne le partage pas encore car il n'est pas encore optimisé et que je vais surement lui rajouter des options de configuration.

Cordialement, PeytaWodka

[Michel Rotta]

Il arrive que les contraintes du cahier des charges oblige a passer par une base préexistante.

Ma recommandation dans ce cas là est d'importer le shema.yml depuis la base de données existante.
De le modifier pour qu'il corresponde le plus possible au modèle objet avec lequel on souhaite travailler, mais sans pour autant que la structure de la base de données générées ne change.
Générer une nouvelle base à partir de ce modèle et vérifier que la base ainsi généré correspondent bien à la base existante.
Une fois ce nouveau modèle conçu et validé, on peut alors revenir à la base de données d'origine et avec un modèle optimisé, au mieux des contraintes.

Ce travail est bien plus long, plus fastidieux, plus difficile que celui qui consiste à partir de rien pour créer ce que l'on veut. De plus le modèle objet sera construit dans un carcan qui risque de nous pénaliser lors des développements. Mais il arrive qu'il n'y ait pas d'autre possibilités.

Je suis très intéressé par ce que pourrait bien faire un module de "nettoyage" de schéma, ma seul crainte est de renforcer certaines personnes qui partent d'une base de données existante pour générer leur modèle plus par paresse que par soucis d'analyse.

[PeytaWodka]

J'ai exactement la même crainte que toi car malgrès que j'ai peu d'expérience je me suis vite rendu compte que de créer un schéma à la main est bien plus puissant que de l'importer car on réfléchit vraiment à quelque chose d'adapter à symfony tout en rajoutant les options propres à Doctrine qui facilite grandement le travail.
J'en suis pas encore là avec mon outil malgrès que je pense pouvoir prendre en compte le behavior Timestampable et peut-être d'autres.

[Michel Rotta]

Les behaviors timestamble et slug sont très configurables, il est notamment possible de changer les nom des champs.

Le modèle est très configurable, il est notamment possible d'avoir un nom de table différent du nom de l'objet et un nom de champ différent du nom de la propriété...

Après certaines propriétés ne sont prises en compte que dans le modèle, d'autre impact la base de données.

Il est aussi possible, pour adapter la souplesse, de travailler directement sur les objets du modèle et de jouer avec les getter et les setter pour adapter encore plus l'objet base à ce que l'on en veut sous symfony.

[PeytaWodka]

J'ai oublié de préciser que malheureusement mon outil est fortement soumis au convention c'est - à - dire que la base de données doit suivre rigoureusement des conventions dans le nom des tables afin que l'on puisse traiter les relations. C'est un gros point noir que j’essaierai de corriger quand j'aurai le temps.

[Michel Rotta]

Tes contraintes ne sont pas définies dans la base ?