I think the way you are extending the SnapshotGenerator is correct. The goal of the class it to handle the database-specific meta-data reading support. Case sensitivity is something that isn’t very well defined in 2.0 but is something I will be trying to standardize with 3.0.
For now, the change you made is just fine.
Nathan
I apologize in advance for the long-winded post…
What exactly is the purpose of the DatabaseSnapshotGenerator and its database specific implementations? I noticed while trying to track down a bug in some code that tags use this interface for resolving column names and table names associated with the .
Here’s little background on the reason I’m asking and what I am seeing. I am seeing the issue in PostgreSQL (8.1.9) using Liquibase 2.0.1. If I have the following example change log:
-
<databaseChangeLog …>
CREATE TABLE myTestTable {
myInteger INTEGER
};
The in 2 will return false and Liquibase will attempt to run the portion and fail because PostgreSQL will throw a column already exists error. If I change the to have an all lowercase columnName:
-
Then, the in 2 will return true and all is well. So it appears that the are doing a case-sensitive comparison on a case-insensitive database (unless of course quotes are added).
I DO NOT see this issue if I use Liquibase’s tag, however we have hundreds of create table statements we don’t want rewrite in Liquibase format. I discovered that if I extend the PostgresDatabaseSnapshotGenerator as follows, all is well:
-
- public class CaselessPostgresDatabaseSnapshotGenerator extends PostgresDatabaseSnapshotGenerator
- {
- @Override
- protected String convertColumnNameToDatabaseTableName(final String columnName)
- {
- return (columnName != null) ? columnName.toLowerCase() : null;
- }
- }
Is this a bug? Is my solution a valid solution in the mean time? If it is, again, what’s the purpose of the DatabaseSnapshotGenerator so I have a better understanding of what I have changed?
Thank you for the response Nathan!