[PYTHON] Conversion automatique du fichier MySQL Workbench mwb en fichier sql
A qui est destiné le document?
Une personne qui utilise MySQL Workbench pour définir une table de base de données (création de diagramme ER)
Quelqu'un qui garde les fichiers mwb sous contrôle de version mais ne peut pas voir les différences (parce que c'est binaire)
Quelqu'un travaille dur pour analyser le XML interne pour traiter mwb comme du texte
Problèmes de gestion des définitions de table avec mwb
Par exemple, supposons que vous créez une table ʻuser comme indiqué ci-dessous, enregistrez-la dans le fichier ʻapp.mwb, et faites git add, git commit.
Eh bien, le développement a continué et nous avons décidé d'ajouter la table ʻarticle.  Supposons que vous écrasiez ʻapp.mwb et que vous fassiez git commit -u.
Maintenant, que voyez-vous lorsque vous regardez ce journal de validation après un certain temps? Vous pouvez voir la différence si vous récupérez les fichiers aux deux révisions et vérifiez le contenu dans Workbench, mais la seule chose facile à voir est généralement la différence entre les fichiers texte. (Ce serait bien s'il y avait un diff mwb comme l'image diff sur github, mais il ne semble pas y avoir une telle chose pour le moment)
Si mwb est binaire, il doit s'agir de texte
Il est possible d'analyser le fichier mwb lui-même (en fait un fichier xml compressé) pour récupérer les définitions de table internes, mais MySQL Workbench a en fait une interface de script Lua`` Python. Cette fois, nous allons l'utiliser pour convertir mwb → sql. Après cela, il semble bon de s'accrocher au moment de git commit et de placer automatiquement le fichier sql sous le contrôle de version. Veuillez imaginer comment le gérer sur le système de gestion des versions.
point important
- Un "affichage" est nécessaire pour lancer l'interface graphique de MySQL Workbench même en utilisant uniquement l'interface de script
- Peu de documentation sur l'utilisation de l'interface de script
- Lors de l'exportation de SQL depuis l'interface graphique, vous pouvez contrôler finement le contenu de sortie, mais lors du vidage depuis l'interface de script, vous ne pouvez sortir que dans un format fixe
Pour le premier numéro, je ne veux pas inclure le système X WIndow juste pour utiliser MySQL Workbench, donc j'utilise le tampon de trame virtuel Xvfb. (Dans le cas de Windows, l'écran apparaîtra un instant, mais abandonnons)
Concernant le second, je l'ai fait en regardant le code de MySQL Workbench lui-même, donc je ne peux pas garantir qu'il soit vraiment correct.
Concernant le troisième, par exemple, ajouter / ne pas ajouter une instruction DROP TABLE peut être contrôlé à partir de l'interface graphique, mais la méthode de fonctionnement à partir d'un script est actuellement inconnue. Cependant, cette fois, le but est de convertir la différence en texte et de la vérifier facilement, donc cela n'a pas beaucoup d'importance.
code
Le référentiel suivant contient le code, les exemples et l'utilisation nécessaires. Un script Python est également intégré dans le corps principal mwb2sql.sh, mais il tient en fait environ 10 lignes.
https://github.com/tomoemon/mwb2sql
La description
environnement
-
WIndows (opération confirmée sous Windows7)
-
Linux (opération confirmée sur Ubuntu12.04)
-
Ici, nous allons vous expliquer comment l'exécuter sous Linux sans afficher l'interface graphique. Pour Windows, c'est plus facile, alors consultez le README dans le référentiel ci-dessus.
Installation
- mysql-workbench 5.2
- Xvfb
Commencez
Activez l'affichage virtuel dans Xvfb. Lorsque vous démarrez Xvfb, vous pouvez recevoir un message sur la police, mais je m'en fiche.
$ Xvfb :1 &
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
Dans cet état, démarrez MySQL Workbench avec un tampon de trame virtuel de 1: 1. Le script Python pour le vidage du modèle est écrit dans mwb2sql.sh, donc lorsque vous le démarrez comme suit, ʻa.sql contient tous les schémas définis dans test.mwb`. L'instruction CREATE de la table est imprimée.
$ DISPLAY=:1 sh mwb2sql.sh test.mwb a.sql
Comme il utilise un tampon de trame virtuel, il devrait fonctionner correctement même lorsqu'il est connecté via ssh.
Le contenu suivant est généré dans ʻa.sql`.
python
-- ----------------------------------------------------------------------------
-- MySQL Workbench Migration
-- Migrated Schemata: mydb
-- Source Schemata:
-- Created: Thu Aug 01 02:32:15 2013
-- ----------------------------------------------------------------------------
SET FOREIGN_KEY_CHECKS = 0;;
-- ----------------------------------------------------------------------------
-- Schema mydb
-- ----------------------------------------------------------------------------
DROP SCHEMA IF EXISTS `mydb` ;
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;
-- ----------------------------------------------------------------------------
-- Table mydb.table1
-- ----------------------------------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`table1` (
`id` INT NOT NULL ,
`name` VARCHAR(45) NULL ,
`created` DATETIME NULL ,
`updated` DATETIME NULL ,
PRIMARY KEY (`id`) )
ENGINE = InnoDB;
SET FOREIGN_KEY_CHECKS = 1;;
Coopération avec git hook
Enfin, combinons ce script avec git hook pour valider automatiquement un fichier textuel sql. Placez le fichier git_pre-commit sur le référentiel en tant que .git / hooks / pre-commit du référentiel que vous utilisez actuellement pour le développement.
Puisqu'il n'y a aucune spécification pour utiliser la mémoire tampon de trame virtuelle dans le script de hook, exportez la spécification DISPLAY. Vous pouvez réécrire le script de hook.
$ export DISPLAY=:1
Dans cet état, essayez git add, git commit tout fichier mwb du référentiel en cours de développement. Un fichier comme test.mwb .__ auto_generated __. Sql doit être créé et automatiquement validé. Dans ce cas, il s'agit d'un hook côté client, mais vous pouvez l'utiliser comme hook côté serveur.
Bonus: pour ceux qui utilisent Workbench uniquement pour dessiner des diagrammes ER
C'est beaucoup plus stable qu'avant, mais il est toujours plus susceptible de tomber ** avec une petite opération, donc je ne le recommande pas comme outil uniquement pour dessiner des diagrammes. Cependant, il existe de nombreuses fonctions uniques à Workbench, telles que la synchronisation de la table réelle sur le serveur de base de données avec le modèle sur mwb et la prise en compte de la différence, donc si vous utilisez Workbench, il est recommandé d'essayer également d'utiliser ces fonctions. Faire.
Recommended Posts