I don't think that the behavior of
will give us any hints. When this is used, the type is already known by the database because you are doing something along the lines of inserting into a column of a knows type, or calling a procedure with a parameter of a knows type. I'm not aware of any case where you would set a parameter in JDBC and the database does not already know its type. The little bit of interesting behavior here is that regardless of the type of the someDate parameter (java.sql.Date, java.util.Date, Calendar, String, ect.), JDBC will trim off any time information. This behavior is closest to the SQL Server DATE data type which never stores any time information.
I'm pretty sure that in the case of the DATE or TIME columns, using the change log properties would not help. If I set a column type to the value of a property, and that property has a value of DATE, Liquibase will still interpret that type and end up using the SMALLDATETIME type as it did when the value of DATE was specified without using a property.
The best solution that I can think of is for Liquibase to allow types to be overridden. This would be very similar to the existing properties feature, but would prevent Liquibase from interpreting the type value when an override is specified. Like the properties feature, we should be able to specify the override values in a properties file, programmatically, or in XML (though any one of those options would satisfy my needs). Using this feature, I could specify something like the following in a change log:
- <typedef type="DATE" value="DATE" dbms="mssql" />
- <typedef type="TIME" value="TIME" dbms="mssql" />
- <typedef type="DATETIME" value="DATETIME2" dbms="mssql" />
Which would make a SQL Server update use the type mapping specified in my initial post when a table is described as usual:
- <createTable tableName="SAMPLE_TABLE">
- <column name="DATE_COL" type="DATE" />
- <column name="TIME_COL" type="TIME" />
- <column name="DATETIME_TO_SECONDS_COL" type="DATETIME(0)" />
- </createTable>
I would be happy to work on such a feature if I thought it would be accepted.
Thanks,
Wesley