Liquibase 3.2.2 Released

Liquibase 3.2.2 has been released. It is a small bugfix release to fix a checksum regression from 3.1 -> 3.2 that was not fixed in 3.2.1.

Issues Resolved:

  • [CORE-1938] – defaultValueNumeric=”0″ or defaultValue=”0″ is translated to 0.0
  • [CORE-1950] – Checksum validation failed after Liquibase upgrade (3.1.1 -> 3.2.0)
  • [CORE-1959] – generateChangeLog without changeLogFile – better error message

As usual, it can be downloaded from the Liquibase download page and is available in the Maven repository as org.liquibase/liquibase-core.


Liquibase 3.2.1 Released

Liquibase 3.2.1 has been released. As usual, it can be downloaded from the Liquibase download page and is available in the Maven repository as org.liquibase/liquibase-core.

3.2.1 is purely a bugfix release. The only potential update issue could be a fix for incorrect checksums introduced in 3.2.0. If you used defaultValueNumeric, defaultValue or used createProcedure or sql tags you may have seen unexpectedly changed checksums with 3.2.0. With 3.2.1, those have been reverted back to the correct 3.1.x version. If you are updating from 3.1.x it will be a smoother update from 3.2.0. If you already updated to 3.2.1 and manually fixed your checksums in the databasechangelog table, they will need to be updated again.

Full change log:

  • [CORE-1844] – bulkFetch of foreign keys on Oracle is very slow
  • [CORE-1918] – Multiple comment blocks in changesets no longer works
  • [CORE-1920] – SpringLiqubase includeAll is not including files
  • [CORE-1922] – 3.2.0 Regression due to CORE-1721
  • [CORE-1923] – Error raised: Unknown Reason when doing tagging via command line
  • [CORE-1930] – Snapshot command returns no information on MSSQL
  • [CORE-1933] – [3.0.8 -> 3.2.0] pom.xml: 2Mb of superfluous dependencies
  • [CORE-1934] – file path in databasechangelog is absoulte since liquibase 3.2.0 when using includeAll inside a jar
  • [CORE-1936] – NullPointerException while diffing database against hibernate.cfg.xml
  • [CORE-1938] – defaultValueNumeric=”0″ or defaultValue=”0″ is translated to 0.0
  • [CORE-1940] – Maximum Oracle Sequence fails to be parsed as a BigInteger
  • [CORE-1944] – NullPointerException when tagging through Ant before applying changesets
  • [CORE-1947] – Liquibase dependency to jetty-servlet/velocity should be <optional>true</optional>
  • [CORE-1950] – Checksum validation failed after Liquibase upgrade (3.1.1 -> 3.2.0)
  • [CORE-1957] – Using VARCHAR2 column type fails for Hsqldb running in oracle syntax mode
  • [CORE-1960] – “Could not find implementation of liquibase.logging.Logger” starts appearing after migration from 3.1.1 to 3.2.0
  • [CORE-1970] – NullPointerException on rollback with <sqlFile> tag
  • [CORE-1746] – Support <sqlFile> parameters
  • [CORE-1951] – Regression on 3.2.0 : –diffTypes=data generates Unknown Reason Exception

UPDATE: There is still a couple checksum issues updating from 3.1.1 to 3.2.1. I’ll get those fixed up in a 3.2.2 release today or tomorrow.

Adding Liquibase on an Existing project

The Quick Start Guide works well for starting Liquibase on a new project because your empty changelog file matches your empty database. However, when you have an existing project with an existing database things are more complicated.

Unfortunately, there is no simple “this is how you do it” answer because there is so much variations in projects, processes and requirements. Liquibase provides many tools to help the process, but it is up to you to decide the best way to combine them for your particular situation.

When adding Liquibase to an existing project there are basically two approaches: “Make it look like you’ve always been using Liquibase” and “Just start using Liquibase”

Make it look like you’ve always been using Liquibase

The goal of this approach is to have a changelog file that matches the current state of your database. You can run this changeLog against a blank database and the final result will be indistinguishable from your existing databases–as if you used Liquibase from the beginning. This approach is usually the best long term, but it can be more work up front.

Create ChangeLog

Creating the changelog to match your database can be done automatically using the generateChangeLog command or be done manually. For any database larger than a few tables, the generateChangeLog command is usually a good idea but make sure you go through the generated changeSets to ensure they are correct. Liquibase does not always detect more complex structures like stored procedures or details like if an index is not clustered. Also, ensure data types are as you expected them.

Populate the DatabaseChangeLog table

Once you have your changeLog, you need a way to ensure that the pre-Liquibase changeSets are only ran on new, empty databases. The easiest way to do this is generally to use the changeLogSync or changeLogSyncSQL command to execute (or generate) the SQL that marks the starting changeSets as already ran without actually executing them.

As an alternative to the changeLogSync command, you can add contexts on the pre-Liquibase changeSets such as <changeSet ... context="legacy"> and when you run Liquibase on a new database you run with liquibase --contexts=legacy update and on an existing database you run with liquibase --contexts=non-legacy.

Finally, you can add <precondition onFail="MARK_RAN"> tags to the generated changeSets. For example, if you have a <createTable tableName="person"> changeSet, you would add <preconditions onFail="MARK_RAN"><not><tableExists tableName="person"/></not></preconditions> tag. Adding preconditions requires more changes to the changeLog file and introduces a performance penalty because Liquibase must check the database metadata for each changeSet the first run through, this approach is usually best used in isolated cases only.

What is the current state?

Often times a part of the reason to move to Liquibase is because your schemas have diverged over time, so an important question to answer is “If I’m making the changelog file match the current state, what is the current state?” Usually the best answer to that question is “the production database” but it can vary.

How divergent your schemas are will also affect which of the above techniques you use to populate the DatabaseChangeLog table, and it will often times make sense to use multiple approaches. For example, you may want to generate your base changeLogs from the production database and use changeLogSyncSQL to be able to mark them ran on everything from production down. Then you can add your non-released changeSets to the changeLog file with a precondition checking if it has already ran. That will allow Liquibase to automatically figure out the correct state for all your databases from development through production.

We are going to use Liquibase starting…..NOW!

Instead of building up a changeLog to match your existing database, you can instead just declare “from now on we are using Liquibase”. The advantage to this is that it much easier to set up because it is just a mandate. Usually this works best going from one version to the next because your databases are all in a reasonably consistent state and you simply start tracking database changes in your next version using Liquibase. Because Liquibase only looks at the DatabaseChangeLog table to determine what needs to run, it doesn’t care what else might be in your database and so it will leave all your existing tables alone and just run the new changeSets.

The biggest disadvantage to this approach is that you cannot bootstrap an empty database with Liquibase alone. A work-around is to take a pre-Liquibase snapshot using your database backup tool and use that as your database seed. Any time you need to create a new database, you first load in the seed and then run Liquibase update.

Depending on how much variation you have between your schemas, even with this approach you may need to rely on preconditions or a “mark changes ran” script in order to standardize and handle those variations.

People and Processes

Finally, remember that starting to use Liquibase–especially on an existing project–isn’t just about how you bootstrap your changeLog file. It is also a question of how you introduce Liquibase into your existing processes and culture.

For many companies and projects, everyone realizes the problems that need fixing and are on board with the advantages of change. For others, however, there can be entrenched interests and strong resistance similar to any other process change. Liquibase provides many tools and approaches that can be used to ease it into an existing process such as SQL outputSQL formatted changelogsdiffChangeLog and more that can be combined in ways that works best for your group.

If you know that introducing Liquibase is going to be complex, either from a technical or processes standpoint, it is usually best to introduce it slowly. Start with it on a new project as a trial run and once you have a good grasp of how it works and available options, apply it to other existing projects.

NOTE: This post has been incorporated into the documentation at

Liquibase 3.2.0 Released

Liquibase 3.2.0 has been released. As usual, it can be downloaded from the Liquibase download page and is available in the Maven repository as org.liquibase/liquibase-core.

For most users, upgrading will be seamless but if you have written Liquibase extensions there have been some API changes. See for details.

Updated Extensions

The following extensions have been updated to work with 3.2.0 and/or include bugfixes:

Major new features and changes in 3.2.0 include:

And/Or/Not logic in context expressions

Context attributes can now include complex expressions such as “qa or (production and master)”. See the context documentation for more information

Improved JSON and YAML changelog parsing

The changelog parsing logic has been greatly refactored to provide full feature parity between the XML, JSON, and YAML parsers.

New Command: Snapshot

The command line interface supports a new “snapshot” command that will output a report of the objects Liquibase sees in a database. This is the model that would be fed into diff/diffChangeLog operations but doesn’t perform any comparison logic, is simply reports on what it sees.

Liquibase SDK

The Liquibase SDK will provide utilities and features not needed for standard Liquibase usage such as testing tools and extension writing help. The 3.2.0 release provides the first pieces of the SDK:

  • Offline Javadoc
  • A starter/example workspace
  • Ability to generate vagrant configurations for various databases
  • “Watch” command to provide a simple real-time view of the database schema

For more information on the SDK, see the SDK Documentation.

Improved Performance

Various improvements in memory usage and optimizations in database interactions

DatabaseChangeLog SQL available with Offline Database

New “outputLiquibaseSql” flag allows inclusion of DatabaseChangeLog table create/insert statements with updateSql command

And Much More:

  • [CORE-209] – Double Create Database Lock Table using updateSQL
  • [CORE-421] – NPE in MySqlDatabaseSnapshot during diff operation when “enum” or “timestamp” column was removed from table
  • [CORE-461] – Wrong datatypes for timestamps generated with generateChangeLog
  • [CORE-871] – Unable to use changeSetPath in rollback tag to refer to another change log file
  • [CORE-877] – Bug with column type “TIMESTAMP WITHOUT TIME ZONE”
  • [CORE-976] – GenerateChangeLog with data: java heap space error
  • [CORE-1097] – Liquibase adds a semicolon after a stored proc definition making the stored proc unusable
  • [CORE-1108] – Oracle : Unable to create complex primary key for loadUpdateData
  • [CORE-1284] – Memory leak in ExecutorService
  • [CORE-1563] – dropAll does not delete Sequences on Derby
  • [CORE-1572] – Regression: diff generates full schema instead of changes when using liquibase-hibernate4
  • [CORE-1578] – changeset checksum calculates differently on linux and windows
  • [CORE-1601] – updateSql generates SQL with unexpected linefeeds, breaks SQLPlus
  • [CORE-1642] – Special character issue after upgrade
  • [CORE-1643] – DB2: defaultSchemaName and changelogSchemaName are not respected
  • [CORE-1650] – dropAll doesn’t work on Informix
  • [CORE-1668] – defaultSchemaName ignored on createTable in H2
  • [CORE-1673] – Empty default value is not recorded for MySQL
  • [CORE-1676] – Colons in changeSet IDs no longer supported
  • [CORE-1688] – The ‘valuum’ extension seems not to be working under version 3.0.8 of liquibase
  • [CORE-1701] – Oracle: snapshot of default date/time values come back as to_date functions
  • [CORE-1714] – 2->3.1 migration error
  • [CORE-1715] – 2 -> 3.1 migration, 3.1 errors if there are single quotes in comments
  • [CORE-1718] – foreignKeyConstraintExists precondition fails with constraints on unique keys
  • [CORE-1721] – HsqlDatabase.escapeObjectName(…) ignores QUOTE_ALL_OBJECTS
  • [CORE-1727] – Drop default constraint syntax for DB2 not correct
  • [CORE-1728] – Only sequence name is captured by snapshot process and used in generateChangeLog
  • [CORE-1733] – Data in diffChangeLog coming through as one row per changeSet
  • [CORE-1734] – updateSQL is not including content from sqlFile (at least not when ran from Linux)
  • [CORE-1739] – Liquibase ignores Oracle varchar precision
  • [CORE-1743] – Snapshot VARCHAR(MAX) correctly on sqlserver
  • [CORE-1744] – Derby: UpdateSQL not including creating databasechangeloglock table if needed
  • [CORE-1748] – Maven Plugin does not use outputDefaultCatalog property
  • [CORE-1750] – liquibase-modify-column 3.0 broken with liquibase-core 3.1.1
  • [CORE-1752] – Oracle XML Datatype snapshot containing size
  • [CORE-1753] – HSQLDB 1.8 does not support catalogs
  • [CORE-1754] – Default value functions on Oracle snapshoted as “defaultValue”
  • [CORE-1755] – DefaultValueComputed is quoted for Char, Varchar, Clob, MediumInt and SmallInt types
  • [CORE-1756] – Oracle indexes with functions not returned correctly in generateChangeLog
  • [CORE-1765] – Failed to drop a VIEW pointing on not existing table from another schema
  • [CORE-1767] – Oracle snapshot not capturing all indexes
  • [CORE-1772] – Informix cannot drop constraints
  • [CORE-1774] – Autocommit not restored on close in SpringLiquibase
  • [CORE-1775] – Informix error when creating primary key
  • [CORE-1779] – User Defined Types Come back with Unnecessary Size specifier in diff
  • [CORE-1782] – dropALL fails when tables are referenced by other tables in another schema
  • [CORE-1784] – GenerateChangeLog with objects in multiple schemas returns objects from multiple schemas and empty createTable statements
  • [CORE-1788] – dropAll does not work in not default schemas using postgresql
  • [CORE-1794] – Drop index failing for sybase
  • [CORE-1797] – Autoincrement on type Serial8 fails
  • [CORE-1798] – Invalid type syntax in Informix for Int(10) and SMALLINT(5) and FRACTION(3)
  • [CORE-1799] – Attempted recreation of DATABASECHANGELOG in informix
  • [CORE-1817] – Foreign Key Constraints Built on Unique Constraints are not captured in generateChangeLog
  • [CORE-1818] – SQL Server “smalldatetime” converted to “datetime” on update
  • [CORE-1824] – GUID Default values not quoted correctly in MSSQL
  • [CORE-1828] – sqlFile should fail when file does not exists
  • [CORE-1831] – CREATE/DROP INDEX issue: Sybase ASE 15.7.0
  • [CORE-1834] – generateChangeLog creates DOUBLE(22) instead of double in MySql
  • [CORE-1840] – Liquibase fails when run on a computer that can’t connect to the internet
  • [CORE-1843] – includeAll does not alphabetize classpath loaded files
  • [CORE-1853] – Liquibase generates invalid SQL for ‘character varying’ type
  • [CORE-1856] – Ability for Change classes to verify update and rollback succeeded
  • [CORE-1859] – DataTypeFactory doesn’t take database into account
  • [CORE-1861] – MSSQLDatabase.isCaseSensitive() provides a wrong information
  • [CORE-1878] – Maven plugin behaviour different than command line with the same parameters
  • [CORE-1881] – Case sensitivity issue with tableExists precondition
  • [CORE-1893] – type=”DATETIME” in changelog is converted to TIMESTAMP in MySql
  • [CORE-1899] – Non-existing referenced sql files doesn’t report error
  • [CORE-1901] – DropPrimaryKey – Fails in Postgres
  • [CORE-1906] – Diff between objects in different named default schemas doesn’t see them as the same object
  • [CORE-1912] – Unit tests fail due to dependency on system time zone
  • [CORE-1116] – Allow for both “AND” and “OR” specifications of which contexts to run
  • [CORE-1422] – Support changeset comments in formatted SQL
  • [CORE-1536] – Support specifying the referenceDefaultSchemaName for diff operations
  • [CORE-1635] – Generated changelog missing unique constraints should be output before foreign keys
  • [CORE-1682] – More machine-independent handling of filesystem-located resources
  • [CORE-1695] – Better handling of Postgres timestamp with/without time zone
  • [CORE-1706] – Excessive reading from databasechangelog table
  • [CORE-1726] – Added offline parameter to generate insert databasechangelog statements
  • [CORE-1758] – Add outputDefaultSchema flags to ant
  • [CORE-1776] – System-independent checksums
  • [CORE-1823] – Search for in classpath in additional to local filesystem
  • [CORE-1874] – Improve XML and other parsers for better extensiblity
  • [CORE-1905] – Yaml parser supports .yml extension as well as .yaml
  • [CORE-1686] – Add Support for Pivotal’s SqlFire database to Liquibase
  • [CORE-1742] – Standardized system for managing configuration options in core and extensions
  • [CORE-1751] – More detailed API for returning changeSet statuses
  • [CORE-1783] – Command line option: snapshot
  • [CORE-1815] – Liquibase SDK command to easily watch database
  • [CORE-1821] – Snapshot listener interface

Slides From Percona Live Talk

I posted the slides from my Percona Live talk at

I modified them from the actual talk slides to also include my speaking notes so they will be more helpful for those who were not able to make it to the talk or if you wish you took better notes.

I’m hoping to post a recorded version of the talk in the next few weeks as well.

Liquibase talk at Percona Live

I’ll be giving a talk at Percona Live in Santa Clara on April 3rd titled “Liquibase: Source Control For Your Schema“.

It is a beginner-level course covering Liquibase basics plus some best practices. More information

If you will be there, stop by and say hi. It’s always great to hear from people using or considering using Liquibase. If you have not yet registered, use the promotional code “SeeMeSpeak” for a 10% discount.

Liquibase-Hibernate Extension 3.3 Released

The Liquibase hibernate extension has been updated for both hibernate 3 and hibernate 4.

Major changes include:

  • Support for Liquibase 3.1.1
  • Support for Hibernate 4.3+ NOTE: Due to hibernate incompatibilities, Hibernate 4.0-4.2 requires the use of the liquibase-hibernate4.2 extension
  • Support for compound primary keys
  • Improved support for detecting auto-increment columns

See for more information and to download the 3.3 release.

The new versions are also working their way through the maven mirror system


Liquibase 3.1.1 Released

Liquibase 3.1.1 has been released with a few bug fixes.

The most important fixes reverts how <createProcedure> checksums are computed so they are compatible with 3.0 and fix the new <rowCount> and <tableIsEmpty> preconditions.

The newest version can be download from

Change log:

  • [CORE-1704] – Checksum errors for changeSets with createProcedure in 3.1.0 vs 3.0.x
  • [CORE-1707] – TableRowCountGenerator shouldn’t pass tableName as catalogName
  • [CORE-1710] – Oracle: NUMBER data type size specification is deployed with a precision specifier even though precision isn’t specified in the change log
  • [CORE-1711] – rowCount doesn’t work if only the tableName is given
  • [CORE-1713] – liquibase.precondition.core.ForeignKeyExistsPrecondition exception
  • [CORE-1715] – 2 -> 3.1 migration, 3.1 errors if there are single quotes in comments
  • [CORE-1709] – generateChangeLog returns tables created by Materialized Views as standard tables


Liquibase 3.1.0 Released

Liquibase 3.1.0 has been released.  For most people 3.1 is a drop in replacement for 3.0.

If you use <includeAll> with relative paths or are running against MaxDB, DB2 for iSeries, or InterSystems Cache make sure you read the  upgrade guide.


Besides bugfixes, 3.1 adds the following major features:

Offline Database Support!

One of the most requested features is the ability to use Liquibase when you do not have direct access to the database. We have always had updateSql support, but it still required a database connection to know what has been ran and what type of database to generate SQL for.

With the new “offline” support, you can now define a database connection URL like “offline:mysql” or “offline:oracle?version=11.1” when you run updateSql.

In offline mode, the change history is tracked in a local csv file which can be controlled with the “changeLogFile” URL parameter. For example: offline:mysql?changeLogFile:/home/db/changelog.csv

For more information, see the offline database documentation

Alternate Changelog History Tracking

With 3.1, you can now create extensions that manage changelog history tracking differently than the standard “DATABASECHANGELOG” table. For example, allows you to manage your changelog history using a local file rather than a table in the database.

New and Improved Change tags:

  • <createProcedure>now supports referencing an external file containing the procedure definition with a new “path” attribute
  • <createProcedure> now supports a dbms attribute to target the database(s) the procedure is compatible with. This allows you to have a single changeSet with a procedure definition for each supported database
  • New <dropProcedure> change
  • <addColumn> supports new “beforeColumn”, “afterColumn” and “position” attributes to control column ordering
  • <sqlFile> files support ${} parameters

New and Improved Precondition tags:

  • <foreignKeyConstraintExists> now supports checking based on table and column definition. Not just constraint name
  • New <tableIsEmpty> precondition
  • New <rowCount> precondition

Database Support Improvements

  • MySQL ENUM and SET type support improvements
  • MySQL support for date/time/timestamp size parameter
  • MySQL support for column remarks
  • MS SqlServer support for sequences (2012+)
  • Sybase general support improvements
  • DB2 general support improvements

Extension/API Improvements

  • liquibase.changelog.visitor.ChangeExecListener implementations are notified of precondition and change-level interactions
  • SnapshotGenerator extensions can block incorrect functionality from other SnapshotGenerators
  • Extensions can define custom XSDs and namespaces

Other Features and Improvements

  • Formatted SQL now supports a comma-separated list in “dbms” targeted changeSets
  • Maven support for futureRollbackSql command


Liquibase 3.0.8 Released

Liquibase 3.0.8 is officially released. It is purely a bugfix release that covers improvements to data type handing, performance improvements, and much more.


Download Liquibase from or from the Maven repository as it winds its way through the mirror process. Visit the user forums if you have any questions.

All Closed Issues

  • [CORE-1224] – Enum column types are not appropriately represented in the change log created by generateChangeLog
  • [CORE-1299] – modifyDataType does not auto reorg on DB2
  • [CORE-1302] – MySQL syntax for autoincrement column with start value
  • [CORE-1357] – Postgresql sequences create error in log files
  • [CORE-1368] – Unable to recreate DB from generated change logs
  • [CORE-1427] – Not generateChangeLog properly for INT2 type for Postgres
  • [CORE-1430] – When I was in sybase database using liquibase create the index, reported “information_schema.constraints” not found error
  • [CORE-1432] – Liquibase H2 InsertOrUpdateGeneratorH2 fails if primary key column name contains $ character
  • [CORE-1446] – Liquibase changelog generation can add linefeed to defaultValueComputed if last column
  • [CORE-1454] – Precondition negation does not seem to work
  • [CORE-1455] – Value not taken into account when inserting data with YAML
  • [CORE-1484] – very poor performance of dropAll on Oracle
  • [CORE-1496] – Custom Change validation happening before being fully initialized
  • [CORE-1531] – includeAll with relativeToChangeLogFile fails under certain conditions
  • [CORE-1537] – Liquibase: diffChangeLog on DB2 performing out of order steps
  • [CORE-1538] – diffChangeLog for DB2 injects invalid characters in xml
  • [CORE-1540] – Call ‘Reorg table’ after modifyDataType on DB2
  • [CORE-1541] – Column type=”LONGVARCHAR” fails
  • [CORE-1545] – Oracle wrong LONG datatype declaration
  • [CORE-1547] – CLONE – H2 (and other) support for BLOB and CLOB is incorrect
  • [CORE-1548] – Oracle Data Type: DATE – defaultValueComputed should be defaultValue
  • [CORE-1549] – Oracle Data Type: INTERVAL YEAR TO MONTH – returned at “INTERNAL(2) YEAR”
  • [CORE-1550] – Oracle Data Type: NCLOB – Receive SQL error when specifying NCLOB size
  • [CORE-1551] – Oracle Data Type: NCHAR
  • [CORE-1552] – Oracle Data Type: NVARCHAR2 – Column sizing is wrong
  • [CORE-1553] – dropDefaultValue does not work on SQL Server
  • [CORE-1554] – dbDoc for Informix IDS
  • [CORE-1555] – Oracle UID reserved word not detected
  • [CORE-1557] – Mysql: BLOB type changes to LONGBLOB
  • [CORE-1559] – Columns defined as “serial” are created as “int” without autoincrement in Postgres
  • [CORE-1562] – update throws Recoverable Exception
  • [CORE-1564] – Broken links in dbDoc
  • [CORE-1566] – DB2 Datatype – DBCLOB, GRAPHIC, VARGRAPHIC doubling datatype size
  • [CORE-1567] – DB2 Datatype – defaultValueComputed being used instead of defaultValue for DBCLOB, TIME, TIMESTAMP, DATE
  • [CORE-1568] – DB2 Datatype – REAL and XML should not have datatype sizes
  • [CORE-1571] – updateDatabase can’t find a changelog
  • [CORE-1572] – Regression: diff generates full schema instead of changes when using liquibase-hibernate4
  • [CORE-1580] – Mysql SET type not handled correctly
  • [CORE-1581] – modifyDataType ignores additional info of newDataType
  • [CORE-1582] – SQLServer datatype for TIMESTAMP
  • [CORE-1583] – Wrong datatype with renameColumn
  • [CORE-1584] – Unable do rollback not in transaction block
  • [CORE-1586] – MySQL DataType – defaultValueComputed being injected into TIMESTAMP, VARBINARY, BINARY, YEAR
  • [CORE-1587] – MySQL Datatype – VARBINARY vs LONGBLOB confusion
  • [CORE-1588] – MySQL DataType – BIT size and default not captured on Snapshot
  • [CORE-1589] – MySQL DataType – BLOB becomes LONGBLOB
  • [CORE-1590] – MySQL DataType – DOUBLE sizing not persisted on snapshot
  • [CORE-1591] – MySQL DataType – TIME not persisting seconds (getting hours and I’ve got that going for me.)
  • [CORE-1592] – MySQL DataType – TEXT converted to LONGTEXT
  • [CORE-1594] – PostgreSQL ‘bigserial’ type is automatically converted to ‘bigint’
  • [CORE-1595] – Schema version incompatibility is logged as INFO instead of WARN
  • [CORE-1596] – Liquibase 3.0.5 will not create tables in dbo schema in SQL Server
  • [CORE-1597] – ORA-01000: maximum open cursors exceeded
  • [CORE-1600] – “Collation” and “Lateral” are not escaped in Postgres (new reserved words in v9.3)
  • [CORE-1602] – DatabaseException in changesets that include date fields with default values
  • [CORE-1603] – MySQL Datatype – BIGINT, INT, MEDIUMINT, SMALLINT, TINYINT all “shaving” off sizes
  • [CORE-1606] – MySQL – TEXT vs. LONGTEXT for diffChangeLog presents CLOB
  • [CORE-1607] – MSSQL java.sql.Types.TIMESTAMP should map to DateTime
  • [CORE-1610] – MSSQL – NTEXT type being snapshot with MSSQL driver default size parameter.
  • [CORE-1611] – Avoid reverse DNS lookup with getLocalHost().getHostName();
  • [CORE-1612] – YAML/JSON changelogs not picking up “value” attribute on column configs
  • [CORE-1614] – mysql case insensitive affects databasechangelog creation
  • [CORE-1615] – Failed to drop default value in MSSQL
  • [CORE-1616] – SQLFileChange uses too many file descriptors
  • [CORE-1619] – MSSQL: preconditions treat object names in a case-sensitive way
  • [CORE-1622] – Ant not respecting diffTypes=data
  • [CORE-1623] – MSSQL: precondition primaryKeyExists doesn’t work
  • [CORE-1625] – H2 Blob Type support is incorrect
  • [CORE-1626] – createIndex does not work for function based indexes anymore
  • [CORE-1627] – Option ‘diffTypes’ does not accept type ‘indexes’
  • [CORE-1632] – It’s impossible to setup Logger’s log level with system property ‘liquibase.defaultlogger.level’
  • [CORE-1636] – Case sensitivity issue with tableExists precondition
  • [CORE-1640] – foreignKeyExists precondition always failing
  • [CORE-1641] – Add column with foreign key throws NPE
  • [CORE-1644] – ValidationFailedException after update to 3.0.7
  • [CORE-1646] – Exception when comparing two schemas
  • [CORE-1647] – Mysql enum default values not quoted
  • [CORE-1648] – Mysql columns with colons and other special chars are not quoted
  • [CORE-1664] – MSSQL. “DATE” type doesn’t exist for MSSQL 2005 and 2000.
  • [CORE-1382] – Allow to create DATABASECHANGELOG* tables in another schema
  • [CORE-1546] – Schema-Support on Informix
  • [CORE-1577] – Oracle tinyint, smallint, int being created as number(38,0)
  • [CORE-1604] – Minor maven pom cleanups
  • [CORE-1635] – Generated changelog missing unique constraints should be output before foreign keys