Bases de données supportées
En raison de variations dans les types de données et de la syntaxe SQL, les bases de données suivantes sont actuellement supportées:
| Base de données | Nom Type | Notes |
|---|---|---|
| MySQL | mysql | Pas de problèmes constatés |
| PostgreSQL | postgresql | La version 8,2 + est requise pour utiliser la fonctionnalité “drop all database objects”. |
| Oracle | oracle | Le driver de la 11g est requis pour utiliser l'outil de comparaison de bases de données pour les bases fonctionnant avec AL32UTF8 ou AL16UTF16 |
| MS-SQL | mssql | Pas de problèmes constatés |
| Sybase Enterprise | sybase | ASE 12.0 + requise. L'option de base de donnée “select into” doit être définie. Le meillieur driver est JTDS. Sybase ne prend pas en charge les transactions pour les DDL, les rollbacks ne fonctionne donc pas lors des échecs. Les clés étrangères ne peuvent pas être supprimées ce qui peut empêcher les restaurations ou l'exécution de la fonctionnalité dropAll. |
| Sybase Anywhere | asany | depuis la version 1.9 |
| DB2 | db2 | Pas de problèmes constatés. Appel automatiquement REORG lorsque cela est nécessaire. |
| Apache Derby | derby | Pas de problèmes constatés |
| HSQL | hsqldb | Pas de problèmes constatés |
| H2 | h2 | Pas de problèmes constatés |
| InterSystems Caché | cache | Pas de problèmes constatés |
| Firebird | firebird | Pas de problèmes constatés |
| MaxDB/SAPDB | maxdb | Pas de problèmes constatés |
| SQLite | sqlite | depuis la version 1.8 Pas de problèmes constatés |
Utiliser des bases de données non pris en charge
Comme Liquibase utilise le standard JDBC, le seul lien qu'elle a à la base de données est le SQL qui peut varier d'un SGBD à l'autre. Si vous essayez d'utiliser une base de données non pris en charge, LiquiBase va essayer de lancer le script de mise à jour et va très probablement réussir. Le seul problème que vous êtes susceptible de rencontrer est le nom de la function date/heure. Si Liquibase est incapable de déterminer la fonction date/heure, vous pouvez la passer en utilisant l'argument currentDateTimeFunction (voir les articles sur la command_line et Ant).
Vous pouvez également rencontrer des problèmes avec le SQL généré par les tags de modification/refactoring pour les bases de données non pris en charge. La meilleure façon de traiter ce type de problème est avant tout d'essayer d'utiliser les tags standards de modification/refactoring. Si cela génère une erreur, vous pouvez utiliser à la place le tag <sql> pour réaliser les changements que vous devez faire, de manière à ce que votre base de données les comprennent.
Si, pour quelques raisons que ce soit, la table DatabaseChangeLog ne peut pas être créée sur votre base de données, voici le SQL de création de la table que vous pouvez modifier pour convenir à vos besoins :
CREATE TABLE DATABASECHANGELOG (id varchar(150) NOT NULL, author varchar(150) NOT NULL, filename varchar(255) NOT NULL, dateExecuted datetime NOT NULL, md5sum varchar(32), description varchar(255), comments varchar(255), tag varchar(255), liquibase varchar(10), PRIMARY KEY(id, author, filename))
Les raisons pour créer vous-même la table DatabaseChangeLog inclues les bases de données nécessitant que les champs NULL soit spécifiés et que les limitations sur les index ne permettent pas l'utilisation de clé primaire sur les champs de type long. Vous pouvez modifier les types de donnée et les longueurs de champs comme vous l'entendez.
