Manuel d'utilisation

Schevo est un modélisateur de bases de données PostgreSQL, MySQL, MariaDB et SQL Server qui enregistre le modèle dans un format adapté à Git : chaque table dans son propre fichier JSON, avec une sortie stable que vous pouvez relire et fusionner comme n'importe quel autre code.

Prise en main

1. Importez votre schéma : Fichier > Importer du SQL… (Ctrl+I) et choisissez le script de création de la base de données. Schevo dessine le diagramme en regroupant les tables par préfixe (cat_, ord_…).
2. Enregistrez le modèle (Ctrl+S) dans un dossier de votre dépôt, par exemple db-model/. Si le SQL provenait d'un fichier, celui-ci reste lié au modèle et il est régénéré à chaque enregistrement.
3. Travaillez et enregistrez : seuls les fichiers qui changent sont réécrits.

À la première ouverture, Schevo charge une boutique en ligne d'exemple pour que vous puissiez tout essayer. Ensuite, il rouvre le dernier modèle au démarrage ; les précédents se trouvent dans Fichier > Ouvrir un modèle récent.

Vous pouvez ouvrir plusieurs modèles à la fois. Si la fenêtre contient déjà un modèle, ouvrir, créer ou importer un autre modèle vous demande s'il faut utiliser une nouvelle fenêtre ou cette fenêtre ; si ce modèle est déjà ouvert dans une autre fenêtre, celle-ci passe au premier plan. Fichier > Fermer la fenêtre (Ctrl+W) ne ferme que la fenêtre courante et Fichier > Quitter les ferme toutes.

Le dossier du modèle

db-model/
  project.json                     nom, schéma par défaut, chemin du SQL, fin de ligne, règles de nommage
  tables/public.cat_product.json   une table par fichier : colonnes, PK, FK, index, position et couleur
  extra.sql                        instructions qui ne sont pas dessinées (séquences, vues, fonctions…), s'il y en a
  diagram.json                     zones et notes du diagramme, s'il y en a

Importer depuis une base de données

Si vous n'avez pas le script de création, Fichier > Importer depuis une base de données… lit le schéma directement dans une base de données PostgreSQL (version 10 ou ultérieure) ; pour MySQL, MariaDB et SQL Server, consultez leurs propres sections. Indiquez l'hôte, le port, la base de données, l'utilisateur et le mot de passe, et cochez Utiliser SSL si le serveur l'exige. Tester la connexion vérifie les informations et liste les schémas pour que vous choisissiez ceux à lire ; si vous n'en choisissez aucun, tous les schémas utilisateur sont lus (jamais pg_catalog ni information_schema).

Le résultat est le même modèle que celui que vous obtiendriez en important le script de création de cette base : tables, colonnes, clés primaires, FK (avec leurs actions), UNIQUE, CHECK, index et commentaires. Les colonnes qui ont leur propre séquence deviennent SERIAL/BIGSERIAL, et les colonnes IDENTITY deviennent des colonnes d'identité, avec les options de leur séquence. Ce qui n'est pas dessiné (schémas, extensions, types ENUM, domaines, séquences, fonctions, vues, déclencheurs, index sur expressions ou partiels, et contraintes EXCLUDE) est conservé dans Projet > Instructions SQL supplémentaires. Les types composites et les types intervalle, les règles, les politiques, les privilèges et les commentaires sur d'autres objets ne sont pas lus.

La connexion est en lecture seule et n'interroge que le catalogue. Schevo mémorise l'hôte, le port, la base de données et l'utilisateur, mais n'enregistre jamais le mot de passe. PostgreSQL réécrit les expressions DEFAULT et CHECK à sa manière (par exemple, BETWEEN devient >= … AND <= … et IN (…) devient = ANY (ARRAY[…])) ; Schevo annule les changements les plus courants dans le texte et, lors des comparaisons et de la génération des migrations, il traite les expressions équivalentes comme égales, de sorte que la base de données et le modèle importé depuis son script ne présentent aucune différence.

La base de données peut aussi servir d'autre version lors d'une comparaison et de point de départ d'un script de migration : choisissez Base de données et cliquez sur Se connecter….

MySQL et MariaDB

En plus de PostgreSQL, Schevo modélise les bases de données MySQL 8.0 ou ultérieur et MariaDB 10.6 ou ultérieur. Chaque modèle a un moteur, affiché dans la barre d'état (un clic ouvre les propriétés du projet) :

• Fichier > Nouveau modèle… demande le moteur du modèle ; le dernier utilisé est présélectionné.
• Fichier > Importer du SQL déduit le moteur du script lui-même (accents graves, ENGINE=, AUTO_INCREMENT, DELIMITER…). En cas de doute, il le demande. Il importe les scripts écrits à la main, les exports du schéma seul (mysqldump --no-data ou mariadb-dump --no-data, avec leurs commentaires /*!…*/, SET, USE et vues provisoires) et les exports qui créent les clés avec ALTER TABLE après les tables. Les données (INSERT…) sont ignorées avec un seul avertissement.
• Dans Projet > Propriétés du projet…, le moteur peut être changé librement tant que le modèle n'a aucune table ; s'il a des tables, seulement entre MySQL et MariaDB. Le schéma par défaut s'appelle ici Base de données : vide signifie « la base de données courante », si bien que les tables sont enregistrées sans schéma (tables/customer.json) et que le SQL généré fonctionne sur n'importe quelle base de données.

Le modèle conserve les particularités de MySQL : UNSIGNED et ZEROFILL dans le type (BIGINT UNSIGNED), ENUM/SET avec leurs valeurs, jeux de caractères et collations de table et de colonne, ON UPDATE CURRENT_TIMESTAMP, colonnes générées (STORED ou VIRTUAL), commentaires en ligne, options de table (ENGINE, ROW_FORMAT, AUTO_INCREMENT=, partitions) et index FULLTEXT, SPATIAL, à préfixe (name(10)) ou USING. AUTO_INCREMENT est une colonne d'identité BY DEFAULT. Les types sont normalisés à l'import (INTEGER → INT, TINYINT(1) → BOOLEAN, sans la largeur d'affichage obsolète des entiers), et la PK prend toujours le nom défini par la convention de nommage du projet, car MySQL ne l'enregistre pas. Une définition d'index accepte column(10) DESC.

Modifier les attributs MySQL : dans un modèle MySQL ou MariaDB, l'éditeur de table (double-clic sur une table ou une colonne) comporte un onglet Options de table avec le moteur, le format des lignes, le jeu de caractères et la collation par défaut, la valeur initiale d'AUTO_INCREMENT, d'autres options et le partitionnement (PARTITION BY …). Sous chaque colonne, vous modifiez son jeu de caractères, sa collation, ON UPDATE et, dans Générée, l'expression d'une colonne générée avec VIRTUAL ou STORED ; pour les index, le type FULLTEXT/SPATIAL et la méthode (USING BTREE ou HASH). Les listes déroulantes proposent les valeurs courantes et en acceptent n'importe quelle autre. Un champ vide signifie « ce que dit le serveur » et n'est pas enregistré ; InnoDB, le moteur par défaut, ne l'est pas non plus. Les valeurs sont écrites comme à l'import (jeu de caractères et collation en minuscules, now() sous la forme CURRENT_TIMESTAMP). Le nom de la PK n'est pas modifiable, car MySQL ne l'enregistre pas. Dans un modèle PostgreSQL, l'éditeur n'affiche rien de tout cela.

Le SQL généré a un format fixe, comme SHOW CREATE TABLE : clés et CHECK à l'intérieur de chaque table, options sur la ligne de fermeture et FK à la fin. Les routines et les déclencheurs (instructions contenant des ;) sont écrits entre DELIMITER $$ et DELIMITER ;, également dans extra.sql et dans l'éditeur des instructions supplémentaires : le script est destiné au client en ligne de commande (mysql database < script.sql), car DELIMITER n'est pas une instruction du serveur.

La validation ajoute les règles de MySQL/MariaDB : ce que le serveur refuse (une seule colonne AUTO_INCREMENT, et dans une clé ; FK entre entiers de taille ou de signe différents ; textes avec des collations différentes dans une FK ; SET DEFAULT ; TEXT ou JSON dans une clé sans préfixe…) est une erreur, et ce qui peut poser problème (tables qui ne diffèrent que par la casse, collations de l'autre variante, DESC sur MariaDB avant la 10.8…) est un avertissement.

Importer depuis une base de données MySQL ou MariaDB : dans Fichier > Importer depuis une base de données…, choisissez le moteur (le port passe à 3306 et Utiliser SSL est coché) ; la base de données est facultative et la liste s'appelle Bases de données. Le modèle est le même que celui que donnerait son script : les tables de la base de données de la connexion n'ont pas de schéma, InnoDB et la collation de la base ne sont pas enregistrés, le compteur AUTO_INCREMENT n'est pas lu, et les vues, routines, déclencheurs et événements sont conservés sans DEFINER. Si MySQL 8 refuse le mot de passe sans SSL, activez SSL : Schevo ne télécharge pas la clé publique du serveur. Le pilote est un fichier séparé, lib/mariadb-java-client.jar (LGPL), qui se connecte aux deux moteurs ; s'il est absent, Schevo le signale. Comme avec PostgreSQL, le serveur réécrit les expressions (accents graves, parenthèses, curdate()…) : les comparaisons et les migrations les comparent sous leur forme canonique.

Script de migration : MySQL et MariaDB n'ont pas de DDL transactionnel, le script n'a donc ni BEGIN ni COMMIT (l'en-tête vous le rappelle : faites une sauvegarde et essayez-le d'abord sur une autre base de données). Les changements de colonne utilisent MODIFY COLUMN avec la définition complète ; les FK sont supprimées avant que leurs colonnes ou l'index qui les soutient ne changent, puis ajoutées à nouveau à la fin ; la PK change en une seule instruction. Les renommages utilisent RENAME COLUMN et RENAME TABLE ; les FK dont le nom change sont supprimées puis ajoutées à nouveau (MySQL n'a pas de RENAME CONSTRAINT). Vous pouvez migrer entre MySQL et MariaDB, mais pas depuis ou vers PostgreSQL ; la comparaison entre moteurs est autorisée. Comparer un modèle MySQL avec l'Exemple fourni utilise la version précédente de la boutique MySQL.

Les exemples de boutique MySQL se trouvent dans le dossier examples/mysql du code source. MySQL et MariaDB sont des marques déposées de leurs propriétaires respectifs.

SQL Server

Schevo modélise aussi les bases de données SQL Server 2017 ou ultérieur et Azure SQL Database. Comme dans PostgreSQL, les tables ont toujours un schéma (dbo par défaut, tables/dbo.customer.json). Ce moteur se choisit comme les autres lors de la création d'un modèle ou dans Projet > Propriétés du projet…, et Fichier > Importer du SQL le reconnaît tout seul (lignes GO, crochets, IDENTITY(1, 1), NVARCHAR…). En ligne de commande, import --dialect sqlserver (ou mssql).

• Il importe les scripts écrits à la main (sans GO ni ; : chaque instruction se termine là où commence la suivante, avec IF OBJECT_ID(…) IS NOT NULL DROP TABLE, des guillemets doubles ou des crochets) et les scripts générés par les outils d'administration du moteur (WITH CHECK ADD CONSTRAINT, ADD CONSTRAINT … DEFAULT ((0)) FOR, options d'index par défaut, ON [PRIMARY]), ceux-ci sans aucun avertissement. Les données sont ignorées avec un seul avertissement ; les vues, procédures, fonctions et déclencheurs sont conservés tels quels.
• Particularités de SQL Server : IDENTITY(seed, increment) (une identité ALWAYS ; l'édition rapide identity la crée ainsi), (MAX) dans le type (NVARCHAR(MAX) ; notes nvarchar(max) en édition rapide et longueur MAX dans l'éditeur), colonnes calculées AS (expression) [PERSISTED], qui n'ont pas de type propre et que le diagramme affiche sous la forme = expression, COLLATE par colonne, ROWVERSION (TIMESTAMP en est l'ancien synonyme, pas une date), index cluster et non cluster (PK NONCLUSTERED, CREATE CLUSTERED INDEX), index avec INCLUDE et index filtrés (WHERE … IS NOT NULL). Les commentaires sont les propriétés étendues MS_Description. L'éditeur de table conserve tout cela lorsque vous validez.
• Chaque contrainte a un nom, les DEFAULT aussi. Lorsque le script n'en donne pas, Schevo utilise un nom fixe (<table>_pk, la convention des FK, <table>_<column>_uk, <table>_<column>_ck, <table>_<column>_df) au lieu du nom aléatoire qu'inventerait le moteur, et le SQL généré l'écrit toujours. Les noms inventés par le moteur (PK__customer__3B75D760) sont conservés et donnent un avertissement qui suggère de les renommer.

Le SQL généré commence par SET ANSI_NULLS ON et SET QUOTED_IDENTIFIER ON, écrit chaque table avec ses index et ses commentaires dans un lot terminé par GO, les FK à la fin, NULL ou NOT NULL sur chaque colonne et des noms qualifiés par le schéma (crochets uniquement si nécessaire). GO n'est pas du T-SQL mais une commande du client : le script est destiné au client en ligne de commande du moteur (avec -b, qui s'arrête à la première erreur) ou à l'éditeur de requêtes de n'importe quel outil. extra.sql et l'éditeur des instructions supplémentaires placent aussi un GO après chaque instruction.

La validation ajoute les règles de SQL Server : un seul index cluster par table, types qui ne peuvent pas être indexés, FK avec des colonnes exactement identiques (type, longueur et collation), et chemins de cascade : le moteur refuse une FK qui laisse deux chemins ON DELETE CASCADE/SET NULL vers une table ou un cycle, c'est donc une erreur (définissez NO ACTION sur l'une d'elles). Un UNIQUE sur une colonne qui accepte NULL est un avertissement, car SQL Server n'autorise qu'un seul NULL : utilisez un index unique filtré.

Éditeur de table : dans un modèle SQL Server, il affiche aussi la case NONCLUSTERED de la PK ; par colonne, la collation, le nom du DEFAULT (vide = le nom implicite <table>_<column>_df) et la colonne calculée (expression et PERSISTED ; elle n'a pas de type) ; par index, CLUSTERED, INCLUDE et le filtre WHERE ; et l'onglet Options de table avec le stockage (ON filegroup) et WITH (…).

Script de migration : le DDL de SQL Server est transactionnel et tout le script s'exécute dans une seule transaction avec SET XACT_ABORT ON ; chaque instruction est placée dans son propre lot, précédée de IF @@TRANCOUNT = 0 SET NOEXEC ON, de sorte que si quelque chose échoue, tout est annulé et le reste (le COMMIT aussi) n'est plus exécuté. Avant un ALTER COLUMN, les index, clés, CHECK, DEFAULT, FK et colonnes calculées qui utilisent la colonne sont supprimés puis recréés (cela peut prendre du temps sur les grandes tables ; élargir un VARCHAR/NVARCHAR qui ne fait pas partie de la PK ne touche pas aux index). Ajouter ou retirer IDENTITY, ou transformer une colonne en colonne calculée, n'a pas d'ALTER : le script le signale par un commentaire « NON MIGRÉ » et la table doit être reconstruite à la main. Les renommages acceptés utilisent sp_rename (y compris pour la PK, les FK et les DEFAULT dont le nom change avec la table ou la colonne). Les nouvelles colonnes sont ajoutées à la fin de la table. Les contraintes dont le nom a été généré par le moteur sont associées par leur contenu lors des comparaisons et des migrations.

Base de données en service : Fichier > Importer depuis une base de données… avec le moteur SQL Server (port 1433) lit le catalogue (sys.*) avec un utilisateur et un mot de passe SQL Server (l'authentification Windows n'est pas utilisée). Le serveur peut s'écrire serveur\instance (le port n'est alors pas utilisé). La case Chiffrer la connexion (cochée par défaut) chiffre la connexion et fait confiance au certificat du serveur, comme sur les serveurs de développement ; sans elle, la connexion n'est pas chiffrée. L'utilisateur a besoin de l'autorisation VIEW DEFINITION : sans elle, SQL Server masque une partie du schéma sans erreur (Schevo le signale). Les tables versionnées par le système, optimisées en mémoire et de graphe ne sont pas lues. En ligne de commande, l'URL contient des ; et doit être mise entre guillemets : schevo-cli import --db "jdbc:sqlserver://server:1433;databaseName=shop;encrypt=true;trustServerCertificate=true" model --user u, avec le mot de passe dans SQLCMDPASSWORD. La comparaison et la migration acceptent la base de données et l'Exemple fourni de SQL Server.

Les exemples de boutique SQL Server se trouvent dans le dossier examples/sqlserver du code source. SQL Server est une marque déposée de son propriétaire.

La fenêtre

• Liste des tables (à gauche) : saisissez du texte pour filtrer ; un clic vous amène à la table et un double-clic la modifie.
• Diagramme (au centre) : les tables avec leur PK en haut, les relations sous forme de lignes (continues lorsque la FK fait partie de la PK de la table enfant, en pointillés sinon) et la patte d'oie du côté de la table enfant.
• Panneau de validation (en bas) : erreurs et avertissements du modèle, mis à jour pendant que vous modifiez. Un clic vous amène à la table et un double-clic l'ouvre. Il peut être réduit, agrandi ou fermé (Affichage > Panneau de validation, Ctrl+Maj+V).
• Barre d'état : le résultat de la dernière action, le nombre de problèmes de validation, le moteur du modèle et, pendant l'essai, les jours restants.

Rechercher (Ctrl+F) cherche dans les tables, colonnes, relations, index et commentaires de tout le modèle. Tous les raccourcis sont listés dans Aide > Raccourcis clavier (Ctrl+F1).

Tables et colonnes

Édition > Nouvelle table… (Ctrl+T) ou un double-clic sur une table ouvre l'éditeur : schéma, nom, couleur, commentaire, colonnes (type, longueur, échelle, NOT NULL, valeur par défaut, commentaire et appartenance à la PK), index et contraintes UNIQUE et CHECK. Identité fait remplir la colonne par la base de données : ALWAYS (toujours) ou BY DEFAULT (seulement quand l'INSERT ne fournit pas de valeur) ; elle est générée sous la forme GENERATED … AS IDENTITY, la colonne devient NOT NULL et elle doit avoir un type entier et aucune valeur par défaut. L'import de SQL ou d'une base de données conserve ses options (START WITH, INCREMENT BY…). À côté de la couleur apparaissent les couleurs déjà utilisées par d'autres tables et zones, pour les réutiliser d'un clic (également dans Édition > Changer la couleur…, Ctrl+K).

Dans le diagramme, le nom de chaque colonne est affiché en demi-gras et son type en gris. Un clic sur une colonne la marque ; si la colonne participe à des relations (c'est une FK, ou d'autres tables y font référence), ces relations ressortent par rapport aux autres relations de la table et la colonne correspondante de l'autre table est marquée. Un double-clic ouvre l'éditeur avec cette colonne sélectionnée. Les types dont la liste de valeurs est très longue (ENUM et SET de MySQL/MariaDB) sont abrégés dans le diagramme, par ex. enum('pending','paid','picking',…) ; le survol de la ligne affiche le type complet, qui figure aussi dans l'éditeur.

• Si vous changez le type d'une colonne vers laquelle pointent des FK (la PK, par exemple), le changement est copié dans les colonnes des tables enfants, puis de là dans les petites-filles, de sorte que les deux côtés de chaque FK gardent le même type.
• Renommer une table met à jour les FK qui y font référence ainsi que les noms de PK et de FK qui suivaient la convention.
• Ctrl+C, Ctrl+V et Ctrl+D copient, collent et dupliquent des tables (y compris entre deux fenêtres de Schevo). Les copies reçoivent le suffixe _copia.
• Suppr supprime la sélection et demande s'il faut aussi supprimer les colonnes FK qui resteraient sans relation.
• Tout peut être annulé avec Ctrl+Z et rétabli avec Ctrl+Y.

Relations

Édition > Nouvelle relation… (Ctrl+R) : choisissez la table parente (celle qui est référencée) et la table enfant (celle qui a la FK). Les colonnes enfants sont proposées à partir de la PK de la table parente ; saisissez un nouveau nom pour les créer. Vous pouvez définir ON DELETE, ON UPDATE, si la relation est identifiante (les colonnes rejoignent la PK de la table enfant) et si elle accepte NULL.

• Sélectionner une relation met en évidence ses colonnes dans les deux tables et affiche des poignées : les extrémités peuvent être déplacées vers n'importe quel côté de la table et le carré central déplace le segment du milieu. Clic droit > Rétablir le tracé automatique annule le tracé manuel.
• Un clic droit sur une table ou une relation permet d'aller à la table parente ou enfant.

Édition rapide

Avec la souris sur le diagramme :

Diagramme, zones et notes

• Glisser sur un espace vide fait défiler le diagramme ; Maj + glisser sélectionne plusieurs tables ; Ctrl + molette zoome autour du curseur (de 10 % à 400 %) ; Ctrl+9 l'ajuste à la fenêtre.
• Sélectionner une table met en évidence ses relations et ses voisines et estompe le reste (Affichage > Mettre en évidence les relations…).
• Minicarte (Ctrl+M) pour se déplacer dans les grands diagrammes et mode compact (Ctrl+Maj+K), qui n'affiche que les colonnes PK et FK.
• Zones : rectangles colorés avec un titre qui regroupent des tables (Diagramme > Nouvelle zone ou clic droit). Faire glisser le titre déplace la zone avec ses tables, le coin la redimensionne et un double-clic sur le titre la renomme. Son nom apparaît aussi sur la minicarte.
• Notes : texte libre sur le diagramme. Double-clic pour modifier et Ctrl+Entrée pour terminer.
• Diagramme > Aligner à gauche et Aligner en haut alignent les tables sélectionnées.
• Diagramme > Disposition automatique… réorganise toutes les tables par préfixe, avec les tables parentes à gauche.

Validation et règles de nommage

Le modèle est validé en permanence. Parmi les erreurs : des FK qui pointent vers des tables ou des colonnes inexistantes, des colonnes de PK qui acceptent NULL, des noms en double, SET NULL sur des colonnes NOT NULL et des valeurs par défaut qui ne correspondent pas au type. Parmi les avertissements : des types différents des deux côtés d'une FK, des cycles ON DELETE CASCADE, des mots réservés et le non-respect des règles de nommage. Vous pouvez enregistrer avec des erreurs, mais Schevo vous prévient d'abord.

Projet > Règles de nommage… définit les conventions des PK, FK, contraintes UNIQUE et index avec les variables {table}, {parent}, {child}, {column} et {columns} (par défaut {table}_pk et {parent}_{child}_fk), ainsi qu'une expression régulière pour les colonnes qui doivent avoir le même type dans toutes les tables (par défaut .*_id). Laissez un champ vide pour ne pas vérifier cette règle.

Travailler avec Git

1. Faites le premier commit (import et enregistrement) à part : le SQL est trié par ordre alphabétique et le changement est important alors que le schéma est le même. Les commits suivants ne montreront que les vrais changements.
2. Validez ensemble le dossier du modèle et le SQL.
3. Comme chaque table est dans son propre fichier et que la sortie est toujours la même, deux personnes qui modifient des tables différentes n'entrent jamais en conflit, et déplacer une table ne modifie que ses lignes x/y.
4. Si une fusion provoque des conflits, résolvez-les dans les fichiers JSON. À l'ouverture du modèle, Schevo indique le fichier et la ligne de tout marqueur <<<<<<< restant. Ne résolvez pas les conflits du SQL à la main : enregistrez le modèle (ou exécutez schevo-cli generate) et il est régénéré.

Changements extérieurs (git pull)

Schevo surveille le dossier du modèle ouvert. S'il change en dehors de l'application (un git pull, un changement de branche, un autre éditeur) :

• sans modifications non enregistrées, le modèle se recharge tout seul, en conservant le zoom, la position et la sélection ;
• avec des modifications non enregistrées, un avis apparaît au-dessus du diagramme avec Recharger, qui abandonne vos modifications et charge les fichiers du disque ;
• si les fichiers contiennent des conflits non résolus, l'avis indique le nombre de problèmes (Voir les détails donne le fichier et la ligne) et le modèle ouvert reste tel quel ; une fois les conflits résolus, il se recharge tout seul ;
• si seul le fichier SQL change, l'avis propose Voir les différences.

Fichier > Recharger depuis le disque (F5) relit le modèle à tout moment.

SQL généré

L'enregistrement régénère le SQL lié (vous pouvez le changer dans Projet > Propriétés du projet…, avec le schéma par défaut et la fin de ligne). Fichier > Générer le SQL… (Ctrl+G) affiche d'abord un aperçu du script avec les différences par rapport au fichier actuel : lignes ajoutées en vert et lignes supprimées en rouge, avec un décompte et une option Changements uniquement. De là, Enregistrer l'écrit dans le fichier lié sans enregistrer le modèle (en demandant où s'il n'y en a pas), Enregistrer sous… l'écrit dans un autre fichier et Copier le place dans le presse-papiers. Exporter le SQL sous… l'écrit directement dans un autre fichier.

Le format est fixe : les tables par ordre alphabétique avec leurs contraintes PK, UNIQUE et CHECK, puis leurs index, et toutes les FK à la fin sous la forme d'un ALTER TABLE. Les instructions que Schevo ne dessine pas (séquences, types, domaines, extensions, vues, fonctions, déclencheurs…) sont conservées telles quelles et se modifient dans Projet > Instructions SQL supplémentaires….

Scripts de migration

Fichier > Script de migration (ALTER)… (Ctrl+Maj+M) génère les instructions qui font passer une base de données existante d'une version précédente du modèle à la version actuelle. La version de départ peut être une révision Git (HEAD, origin/develop, une étiquette…), la dernière version enregistrée, un autre modèle ou script SQL, ou le schéma actuel d'une base de données (Base de données > Se connecter…), ce qui donne exactement ce qu'il reste à lui appliquer.

Renommages. La comparaison de deux versions ne permet pas de savoir si une colonne a été renommée ou supprimée puis remplacée par une autre, et la suppression suivie d'un ajout fait perdre ses données. Schevo recherche donc les renommages possibles et les liste au-dessus du script : une table supprimée et une table ajoutée avec les mêmes colonnes, ou une colonne supprimée et une colonne ajoutée du même type. Les correspondances évidentes sont cochées ; les douteuses ne le sont pas. Les renommages cochés sont écrits sous forme de RENAME (y compris les PK et FK dont le nom change avec la table) et les données sont conservées ; ceux qui ne sont pas cochés restent une suppression et un ajout et sont listés dans un commentaire à la fin du script.

Relisez toujours le script avant de l'exécuter : un renommage que vous ne cochez pas est perdu (suppression et ajout) et les changements de type peuvent échouer si les données existantes ne peuvent pas être converties.

Comparer des versions

Fichier > Comparer avec une autre version… (Ctrl+Maj+C) marque sur le diagramme les nouvelles tables (en vert), les tables modifiées (en orange, avec les colonnes modifiées mises en évidence) et les tables supprimées (en rouge, en pointillés). Liste des changements détaille chaque différence et vous amène à la table. Les positions et les couleurs ne comptent pas comme des changements, pas plus que les expressions DEFAULT et CHECK écrites d'une autre manière équivalente (par ex. x BETWEEN 0 AND 4 et (x >= 0) AND (x <= 4)) ; elles ne produisent pas non plus d'instructions dans les scripts de migration. Vous pouvez comparer avec une révision Git, la dernière version enregistrée, un autre modèle ou script SQL, ou une base de données en service (Base de données > Se connecter…), par exemple pour voir ce qui manque à la base de production. Un exemple fourni vous permet de l'essayer.

Export et dictionnaire de données

• Fichier > Exporter une image PNG / SVG / PDF : tout le diagramme, toujours avec le thème clair.
• Fichier > Exporter le dictionnaire de données (HTML) : un seul fichier avec le diagramme, un index avec recherche et, pour chaque table, ses colonnes, clés, index, contraintes, commentaires et relations liées.

Ligne de commande et intégration continue

schevo-cli est installé à côté de l'application :

validate et check ne nécessitent pas de licence : vous pouvez donc les utiliser sur n'importe quelle machine d'intégration continue. Hook de pré-commit pour que le modèle ne soit jamais envoyé sans son SQL :

#!/bin/sh
schevo-cli check db-model || { echo "Exécutez : schevo-cli generate db-model"; exit 1; }

Licence

Schevo comprend un essai de 30 jours avec toutes les fonctionnalités. Ensuite, sans licence, il fonctionne en lecture seule : vous pouvez ouvrir, parcourir, rechercher, comparer et exporter en images vos modèles, mais pas les modifier ni les enregistrer, ni générer du SQL, des migrations ou le dictionnaire. Vos fichiers ne deviennent jamais inaccessibles.

Saisissez votre clé dans Aide > Licence… ou avec schevo-cli license --activate <key>. La clé est vérifiée sans connexion Internet. Une licence perpétuelle fonctionne pour toujours avec les versions publiées pendant sa période de mises à jour ; un abonnement fonctionne jusqu'à sa date d'expiration.

La date d'expiration d'un abonnement inclut déjà un délai de grâce de 14 jours après la période payée. Pendant ces 14 derniers jours, vous pouvez continuer à travailler normalement, mais la barre d'état indique le nombre de jours restants et, au démarrage (au plus une fois par jour), une fenêtre vous rappelle de renouveler avant que Schevo ne passe en lecture seule. Depuis cette fenêtre, Saisir une nouvelle clé… ouvre Aide > Licence… pour activer la clé renouvelée.

Mises à jour

Aide > Rechercher des mises à jour… demande la dernière version au site web de Schevo et vous indique si vous êtes à jour. Lorsqu'il y en a une nouvelle, il affiche sa date de publication et ses nouveautés, et Télécharger ouvre la page de téléchargement dans votre navigateur. Schevo n'installe jamais rien tout seul.

Par défaut, Schevo vérifie aussi au démarrage, au plus une fois par jour et en arrière-plan. S'il y a une nouvelle version, un avis apparaît au-dessus du diagramme ; si la vérification échoue (par exemple, sans Internet), rien n'est affiché. Pour la désactiver, décochez Aide > Rechercher automatiquement les mises à jour.

Si vous ne voulez pas installer une version donnée, cliquez sur Ignorer cette version dans l'avis : elle ne vous sera plus annoncée au démarrage, mais la suivante le sera. Aide > Rechercher des mises à jour… l'affiche quand même (en indiquant que vous l'avez ignorée), au cas où vous changeriez d'avis et voudriez la télécharger.

La vérification ne télécharge qu'un petit fichier public depuis le site web : elle n'envoie ni votre version ni aucune donnée vous concernant ou concernant vos modèles. La comparaison des versions se fait sur votre ordinateur.

Langue, thème et préférences

• Affichage > Langue : espagnol, anglais, allemand ou français (appliqué au redémarrage). Par défaut, la langue du système est utilisée.
• Affichage > Mode sombre (Ctrl+Maj+D).
• Schevo mémorise le dernier modèle, le dernier dossier, le thème, le mode compact, la minicarte et la taille du panneau de validation.

Récupération et dépannage

• Tant qu'il y a des modifications non enregistrées, une copie de récupération est faite toutes les 2 minutes. Si Schevo se ferme de manière inattendue, il propose de la récupérer à la prochaine ouverture.
• Si une erreur inattendue apparaît, le bouton Copier le rapport copie les détails techniques pour que vous puissiez les envoyer au support.
• Le journal de l'application se trouve dans %LOCALAPPDATA%\Schevo\logs sous Windows et dans ~/.schevo/logs sous Linux (Aide > À propos de Schevo > Ouvrir le dossier des journaux).