Nathan

This seems a working solution. Except that you are correct, the presented code would fail on function change

Problem here is that it becomes a bit hard to see which changes have been applied to the database and which weren't.

The only thing you know is that "when sproc A was last replaced at <timestamp>, the SQL code hashed to a value of <hash>".

Since you don't have a ready hash of the resulting changeset, it might be a bit hard to identify in case of any discrepancies. This could be a moot point if you have other ways of tracking deployed versions, of course...

we would like introduce LiquiBase  in Telekom Germany on a big project.  How can we introduce LiquiBase into our development, because it is not a new project older than  4 years.

Is it possible the reverse engineering with LiquiBase   ?  

As far as I can see the generateChangeLog   create change log only from tables and view  ,  not from materialized views and packages , procedures and so on,

I am working on one java spring boot based project and using liquibase as my middle layer, Using database sequence for entity ID.
so I have below liquibase changeSet and which is not creating sequence on SQL server (version - Microsoft SQL Azure (RTM) - 12.0.2000.8).

Please let me know if there is some solution to resolve it (Liquibase version is 2.0.1).

Thank you.

C:\Liquibase>liquibase update<br>Starting Liquibase at Wed, 16 Jan 2019 19:07:25 IST (version 3.6.0 built at 2018-04-05 05:13:19)<br>Unexpected error running Liquibase: Column, parameter, or variable #2: Cannot find data type BOOLEAN. [Failed SQL: CREATE TABLE DATABASECHANGELOGLOCK (ID INT NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED datetime, LOCKEDBY VARCHAR(255), CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID))]<br>liquibase.exception.LockException: liquibase.exception.DatabaseException: Column, parameter, or variable #2: Cannot find data type BOOLEAN. [Failed SQL: CREATE TABLE DATABASECHANGELOGLOCK (ID INT NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED datetime, LOCKEDBY VARCHAR(255), CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID))]<br> at liquibase.lockservice.StandardLockService.acquireLock(StandardLockService.java:289)<br> at liquibase.lockservice.StandardLockService.waitForLock(StandardLockService.java:207)<br> at liquibase.Liquibase.update(Liquibase.java:184)<br> at liquibase.Liquibase.update(Liquibase.java:179)<br> at liquibase.integration.commandline.Main.doMigration(Main.java:1205)<br> at liquibase.integration.commandline.Main.run(Main.java:191)<br> at liquibase.integration.commandline.Main.main(Main.java:129)<br>Caused by: liquibase.exception.DatabaseException: Column, parameter, or variable #2: Cannot find data type BOOLEAN. [Failed SQL: CREATE TABLE DATABASECHANGELOGLOCK (ID INT NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED datetime, LOCKEDBY VARCHAR(255), CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID))]<br> at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:356)<br> at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:57)<br> at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:125)<br> at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:109)<br> at liquibase.lockservice.StandardLockService.init(StandardLockService.java:97)<br> at liquibase.lockservice.StandardLockService.acquireLock(StandardLockService.java:246)<br> ... 6 common frames omitted<br>Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Column, parameter, or variable #2: Cannot find data type BOOLEAN.<br> at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:217)<br> at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1655)<br> at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(SQLServerStatement.java:885)<br> at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(SQLServerStatement.java:778)<br> at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7505)<br> at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2445)<br> at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:191)<br> at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:166)<br> at com.microsoft.sqlserver.jdbc.SQLServerStatement.execute(SQLServerStatement.java:751)<br> at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:352)<br> ... 11 common frames omitted<br><br><br>For more information, please use the --logLevel flag

Nathan

1. ALTER (modify or adding column)

   Throwing excetion that SQL syntax is NOT correct.

2. forIndexName is NOT supported for SAP HANA

3. In Squence creation, ordered = false is NOT supported

4. trigger syntax needs to be changed as per SAP HANA DB

Please help to give suggestions or direction  that without any making changes in the liquibase-changes.xml and  also in liquibase core library changes, How to make common liquibase-changes.xml for both DBs ? and also so In order to work ALTER command need to change the liquibase core libraries.. how to avoid to touch the core libraries changes?

With liquibase-3.5.3,  I was trying to retrieve a datetime ( datetime(3) ) column schema info from MySQL and found out [ColumnSize] returned was always 19 but not the one I saw in db, e.g. 3 for datatime(3). Therefore, please advise what was going wrong ?

There is a comment I am not sure if it is helpful for the answer :

According to the description of DatabaseMetaData.getColumns, the content of the "COLUMN_SIZE" column is

         * pretty worthless for datetime/timestamp columns:

         *

         * "For datetime datatypes, this is the length in characters of the String representation

         * (assuming the maximum allowed precision of the fractional seconds component)." 

Also, from the logic, columnSize in DataType.class is directly assigned to CachedRow.getInt("COLUMN_SIZE"). So, any possibility of COLUMN_SIZE is not fully covering DATATIME_PRECISION in MySQL schema info ?

automatic lock prolonging (and with this, removal of stale locks) is quite important in microservice environments, especially where developers don't have access to the production database and hence cannot manually remove locks there.

I started working on https://liquibase.jira.com/browse/CORE-2375 and got a prototype working, however only on an older branch.

I haven't been able to get the newer branches to work even without modifications, see https://www.zohodiscussions.com/liquibase#Topic/49382000001952005

My solution seems to work so far, only drawback is that I am creating two JDBC connections now, as the prolonging lock service asynchronously prolongs its lock and hence needs its own transaction (it would otherwise rollback or commit changes the actual updater is doing).

The prolonging lock service is not activated by default, but even when its deactivated, and the standard lock service is used, I'm creating two connections.

I'm not sure if that might cause problems in situations where people use a JDBC pool (with size 1). Maybe we should do another check and only create two connections in case the prolonging lock service got activated.

Looking forward to hear your feedback, or get some review comments (see pull request in the ticket).

Best

Bernhard

DATICAL PERMISSIONS

• Needed for all environments (note, some of the permissions are optional depending on criteria shown beside each one).

Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/

So for instance the below did not work ---> (liquibase-custom.jar would not be loaded only the jsqlconnect jar would be loaded and it wouldn't find my custom hello world extension) 

Below however, did work and added my custom jar to the classpath so it got loaded when the parser loaded the helloWorld change. 

My observation is that the XML diff files use some kind of cross-platform format for data types but when applying them to MySQL it seems to convert to the correct type.

I'd like some kind of a confirmation from the developers that this is indeed the case.