Liquibase DB dialects

Liquibase Development
1

Hello,

I had a task to consider Liquibase for managing databases for modular java project.
In the end the conclusion is that Liquibase is the right tool for the job but it has several bugs that have to be fixed.
These bugs/issues were fixed in a local branch and, of course, it would be perfect if they could be accepted in the main branch.
While some of these fixes, like generating correct composite primary key with generateChangeLog, I believe could be accepted, others like data types mapping requires some structural changes in the project…

The project I’m working at is using Hibernate, the intention is to let Liquibase to create the database structure and insert the data, while Hibernate will only validate the database structure. While testing I got issues like:
https://liquibase.jira.com/browse/CORE-1288, because the script
was creating a LONGVARCHAR and hibernate validation failed because it expected a CLOB.
Here I’d like to quote Nathan Voxland:
“I’m still trying to think through how to best handle that cross-database logic. It seems like it is always wrong in one case or another.” from here (https://github.com/liquibase/liquibase/pull/100#issuecomment-13015492).

The fact is that I want a CLOB there, but someone else wants a LONGVARCHAR and in this situation, to satisfy everyone, it is required these things to be configurable. I think Liquibase could use something similar to Hibernate dialects. This configuration-mapping can be placed in xml files, or in java files or mixed - in xml, with possibility to indicate in xml the name of a java class that processes the mapping for complex cases.

Liquibase could provide a set of standard dialects, enabled by default that would perform exactly as it does now, keeping in this way the compatibility with the current/previous versions.

Additional Liquibase could provide additional dialects for different tasks, for example for those who use hibernate and need a mapping that would be compatible with hibernate validation.
The dialects could be submitted by developers and users and kept in a catalogue/library.

Please let me know what you think about this.

2

That route may work well and has worked well for hibernate. If you have a proposed change put it in a branch and create a pull request and we can work through it. How to handle datatypes better is something I’m hoping to address in 3.1 so any suggestions would be greatly appreciated.


Nathan

3

We’ve discovered possibility to extend LiquibaseDataType and make it’s priority bigger than DEFAULT.
So translation logic can be overridden easily in the way we want.
This is discussed here http://forum.liquibase.org/topic/custom-type-converter

This feature is not documented but we consider it very important, since default data type translation in some cases needs to be adjusted.