Générateur yml ?

[gui80]

Bonjour à tous,

pardonnez cette question mais m'initiant à l'ORM Doctrine, je me demandais s'il n'existait pas des générateurs yml.


Merci d'avance pour vos précisions/aides.

[Michel Rotta]

Il y a MySql Workbench qui a un plugin pour générer du yml qui marche presque bien.

Il n'existe aucun générateur réellement parfait à ma connaissance et il convient toujours de terminer (peaufiner) le shema.yml à la main.

[Benjamin Delespierre]

Hello

C'est YAML le nom du format ? Pour YAML Ain't Markup Language...

Enfin moi ce que j'en dis.

[Michel Rotta]

yml nom d’extension pour yaml nom du format.

Même combat.

La question reste pour qui peut en faire pour doctrine 1.2

Et que ce soit yml ou yaml n'entre pas vraiment en ligne de compte.

[gui80]

Re et merci pour les précisions.

d'accord pour mysql workbench.
Par contre, je suis sous PostgreSQL, c'est dommage.


Bien noté que cela ne fait pas tout le travail, mais au moins, çà peut faire gagner du temps.

Y aurait-t-il des générateurs pour postgresql ou même plus générique ?
Ou faudrait-il se lancer dans le codage d'un générateur,


Bien noté pour le yml et yaml

[Michel Rotta]

Je pense que, pour un début convaincant d'un shema.yml, MySQL W devrait suffir, même pour PostrgreSQL, après-tout doctrine est une couche commune a toutes les bases et va convertir les demandes en fonction du SGBD choisi. Les shema.yml sont, en principe, utilisable sur toutes les bases. Ou avec un minimum de modifications.

Écrire un générateur me semble un peu vain comme démarche. Le format entre la version 1.2 et la version 2.0 du "shema.yml" est plus que substantiel et pas nécessairement souhaitable en 2.0. Ce serait donc écrire un générateur presque mort né.

[Benjamin Delespierre]

Si ça vous branche, je suis en train d'écrire dans un autre topic des classes de réflexion pour les base de données (MySQL pour l'instant).
Vu que c'est plus ou moins connecté au sujet du Topic, venez donc jeter un oeil

C'est par ici: http://www.developpez.net/forums/d10...se-reflection/

Dans ce thread, je prends à contrepied le mécanisme de Doctrine qui consiste à utiliser YAML pour connaitre le schéma en fournissant un jeu de classes de réflexion (sur le thèmes des classes Reflector de PHP) capable de comprendre la structure d'une base données relationnelle en interrogeant le schéma.

[Michel Rotta]

Envoyé par Benjamin Delespierre

Dans ce thread, je prends à contrepied le mécanisme de Doctrine qui consiste à utiliser YAML pour connaitre le schéma en fournissant un jeu de classes de réflexion (sur le thèmes des classes Reflector de PHP) capable de comprendre la structure d'une base données relationnelle en interrogeant le schéma.

C'est une approche intéressante et je vais suivre su sujet.

Par contre, Doctrine 1.x n'utilise pas le yaml pour connaître le schéma de la base. Il utilise le schéma pour définir les objets permettant d'accéder aux données et créer une structure physique de données compatible avec les besoins du modèle. Ce qui n'est pas la même chose.

Dans ton approche, tu parts d'une structure physique des données pour y accéder. Alors que de plus en plus doctrine part d'une structure logique et du modèle pour générer la structure physique qui pourra y répondre.

Les deux approches sont intéressantes, même si, pour l'instant, j'ai plus usage de celle de Doctrine.

[Benjamin Delespierre]

Par contre, Doctrine 1.x n'utilise pas le yaml pour connaître le schéma de la base. Il utilise le schéma pour définir les objets permettant d'accéder aux données et créer une structure physique de données compatible avec les besoins du modèle. Ce qui n'est pas la même chose.

J'ai moi aussi employé cette approche en créant mon modèle DAO (il a pas mal de temps). Les classes SQLRow interrogeaient des services TableInfo et SQLQueryMaker qui lisaient grossièrement le schéma (à grand coups de DESC).
Je voulais un mécanisme plus propre, plus industriel et plus faiblement couplé.

Comme tu le verra dans le thread, le problème de l'approche descendante (celle de Doctrine) est qu'elle suppose que l'application PHP à le contrôle de la structure des tables ou que cette structure ne change pas. Dans mon environnement de travail, je ne peux pas me permettre un tel luxe, c'est pourquoi j'essaie de développer un mécanisme ascendant.

[Michel Rotta]

Envoyé par Benjamin Delespierre

Comme tu le verra dans le thread, le problème de l'approche descendante (celle de Doctrine) est qu'elle suppose que l'application PHP à le contrôle de la structure des tables ou que cette structure ne change pas. Dans mon environnement de travail, je ne peux pas me permettre un tel luxe, c'est pourquoi j'essaie de développer un mécanisme ascendant.

Je ne critique pas l'approche depuis le modèle physique.

Mais il faut rester réaliste, dans la très grande majorité des cas, c'est l'application qui impose le modèle des données plutôt que le contraire.

Reste quelques cas particulier dans le genre de phpMyAdmin (qu'il pourrait être intéressant de démonter dans ce cas) mais cela reste plutôt des exceptions que des habitudes.

[Benjamin Delespierre]

Je ne critique pas l'approche de Doctrine.

Mais je suis dans le cas ou l'application PHP est l'IHM d'une autre application serveur. Les base de données sont susceptibles de changer (presque) sans préavis.

Je suis pas sûr que phpmyadmin soit un modèle fiable.

[Michel Rotta]

Fiable je ne sais pas, mais source d'inspiration, je pense

[gui80]

Bonjour,

pour mysql workbench, cela ferait que je devrai à nouveau définir mes tables, mes relations et autres.

Par contre, j'ai power architect et avec une connection jdbc, je peux récupérer la structure de mon schéma de BD.

Il y a un plugin qui semble correspondre à ce que je souhaite, c'est :

https://github.com/dbaAlex/YAML-Schema-Exporter-Plugin

J'essaierai de jeter un œil au lien de Benjamin quand je peux, je ne connais pas bien la notion de reflector.

[Michel Rotta]

Je ne connais pas ce module et n'ai jamais vu de yml généré par lui.

J'ai très peu confiance dans les générateurs, celui de MySql W. est le moins mauvais (ce qui ne veut pas dire que l'on ne puisse faire mieux).

Pour l'instant je n'en connais pas qui puisse fonctionner sans une retouche manuel de shema.yml généré.

Ne pas oublier que nous définissons un schéma objet pour l'accès au données et que doctrine en fait une base, le contraire est possible mais n'est jamais une bonne approche.

[gui80]

Cela me génère bien un .yml avec ce plugin mis dans power architect.

On est d'accord que l'on ne peut pas se contenter tel quel du fichier généré par le générateur.

1ère question : Y a-t-il des docs qui décrivent les options autorisés dans des yml de config doctrine ?

2ème question : j'ai suivi des tutoriaux sur doctrine 1.2, sachant pertinemment que la v2.0 est déjà sorti, mais trop récemment pour avoir des tutoriaux sur la v2. Peux-tu me dire brièvement les changements dans les fichiers .yml entre la v1.2 et la v2 ?


Oui, j'ai bien saisi le fait que doctrine lit le fichier yaml et conçoit son modèle objet à partir de ce fichier.

[Michel Rotta]

1) la documentation de doctrine.

2) sur la deux, j'ai décidé de laisser tomber les yaml pour utiliser la configuration par annotation dans un fichier php. Plus souple même si c'est moins lisible.
Je n'ai pas trop regardé la génération depuis des fichiers yaml, pas encore.

[gui80]

Pour la 1, question idiote de ma part

Pour la 2, tu fais dans un fichier php ? tu fais tout manuellement sans générateur yaml via mysql workbench du coup, c'est çà ?

Qu'est ce qui t'a fait abandonner le fichier yaml au profit du php ?
La v2 de doctrine complique toute la config via un fichier yaml ?

Désolé pour ma curiosité, mais j'aimerai essayer profiter au mieux de l'expérience que tu as pour avoir divers informations concernant cet orm.

[Michel Rotta]

Je n'ai aucun projet actuellement en production qui utilise la 2, juste des études (pas même encore de vrai début de développement).

Dans Doctrine 2, on utilise un fichier php "libre" (Il n'y a pas de classe de base pour les tables). Il n'y a pas non plus la notion de fichier de base et de sa surcharge (c'est bien sur réalisable, mais entièrement manuellement). Cette absence notamment et l'habitude que j'avais jusqu'à présent de l'utiliser beaucoup pour remplacer les type enum qui je n'utilise pas.

Ces différentes raisons font que j'utilise les fichiers php et les annotations. Depuis j'envisage de faire un essai avec un yaml, de nommer mes entités xxxxxBase et de systèmatiquement créer une classe xxxxx qui sera enfant de xxxxxBase et permettra d'étendre les objets. Faut que je trouve le temps de voir si c'est plus viable que de le faire à la main et quel doit être la structure de namespace et de dossier permettant de le faire fonctionner simplement et efficacement.

Donc, pour l'instant, j'utilise les fichiers php plat et les annotations, mais sans savoir si ce sera ma préconisation.

Accessoirement, j'attends un peu pour voir ce que va préconiser sensio.

[gui80]

Bonjour et merci pour les précisions.

Il faut rester sur une version antérieure à la v2 et attendre que les choses se clarifient.

Oui, moi aussi, c'est pour l'utiliser ensuite avec symfony.

[Michel Rotta]

Envoyé par gui80

Il faut rester sur une version antérieure à la v2 et attendre que les choses se clarifient.

Ce qui n'est, hélas, pas possible avec Symfony2