Skip to content

Latest commit

 

History

History
52 lines (42 loc) · 3.62 KB

databases.md

File metadata and controls

52 lines (42 loc) · 3.62 KB
layout title
default
Databases

Supported Databases

Due to variations in data types and SQL syntax, the following databases are currently supported out of the box. Additional databases as well as enhancements to support for the below databases are available through Liquibase extensions

Please find further information about which jdbc driver, url, classes etc. these databases need, with clicking on the specific link.

DatabaseType NameNotes
MySQLmysqlNo Issues
PostgreSQLpostgresql8.2+ is required to use the "drop all database objects" functionality.
Oracleoracle11g driver is required when using the diff tool on databases running with AL32UTF8 or AL16UTF16
Sql ServermssqlNo Issues
Sybase_EnterprisesybaseASE 12.0+ required. "select into" database option needs to be set. Best driver is JTDS. Sybase does not support transactions for DDL so rollbacks will not work on failures. Foreign keys can not be dropped which can break the rollback or dropAll functionality.
Sybase_AnywhereasanySince 1.9
DB2db2No Issues. Will auto-call REORG when necessary.
Apache_DerbyderbyNo Issues
HSQLhsqldbNo Issues
H2h2No Issues
InformixinformixNo Issues
InterSystems CachécacheNo Issues
FirebirdfirebirdNo Issues
MaxDB / SAPDBmaxdbNo Issues
SQLitesqliteNo Issues

Using Unsupported Databases

Since Liquibase is built on top of standard JDBC, the only ties it has to the underlying database is through the SQL that can vary from DBMS to DBMS. If you attempt to use Liquibase with an unsupported database, it will try to run and will most likely succeed. The only problem you are likely to run into is the current date/time function name. If Liquibase is unable to determine the correct date/time function, you can pass it in via the "command line" and documentation/Ant).

You may also run into problem with the SQL generated by the change/refactoring tags on unsupported databases. The best way to deal with this problem is to first try the standard change/refactoring tags. If it generates an error, you can fall back to the sql change to code whatever change you need to make in a way that your database understands.

If, for some reason, the DatabaseChangeLog table cannot be created on your database, the base creation SQL that you can modify to suite your needs is:

{% highlight sql %} 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)) {% endhighlight %}

Reasons for creating the DatabaseChangeLog table yourself include database that require null fields to be specified as such and index limitations that don't allow primary keys on fields as long. You can change the data types and or data type lengths all you want,