Is there anyway to reference the changeLog id in your sql? We're in the middle of moving our database over to liquibase, but we already have an Environment table which has key value pairs, one of which is "database_version". I want all our liquibase changes to also update the value for the "database_version" with the change_log id.
There is nothing built in, but the extension system (http://liquibase.org/extensions) will allow you to implement it yourself.
The easiest approach would probably be to add a liquibase.changelog.visitor.ChangeExecListener implementation updates your table after each change is executed.
Related
I have introduced a changeset <dropTable table_name="foo"> that will get rid of the no longer needed table foo.
Since dropTable has no auto-rollback I can of course specify the rollback actions manually (by copying the contents of the changeset that originally created foo). It would however be more convenient and less error-prone to just re-apply the said changeset - is this possible?
Update: it is possible, the answer is hidden in the Liquibase Auto Rollback subpage of using-rollback which does not only list change types and their auto-rollback capability but also has an example of referring to an older changeSetId.
However, this feature seems not to be the most powerful: if the changeset in question is stored in another file (we have all minor versions in separate files which are put together by "include file=..." tags) the changeset is not found.
Plus it's only possible to specify one changeset, so if the table in question has been created using multiple change sets (e.g. adding foreign keys in an extra step) specifying just one set to apply will not get us to the original DB setup.
That is an interesting question. 2 conditions have to be met in order to re-apply the changesets
Have a changeste with runAlways attribute (Examplel can be found here: https://docs.liquibase.com/concepts/basic/changeset.html?Highlight=runalways)
Have a precondition that is evaluated prior to running the changeset.- https://docs.liquibase.com/concepts/advanced/preconditions.html?Highlight=pre%20condition
We are using liquibase to split a column into two columns. This happens in three changes:
Add the new columns via addColumn
Insert the data from the old column into the new ones via a customChange
Delete the old column via dropColumn
This works great, but I can not find any documentation on the order of execution of changes.
I only found documentation on the order of execution of changeSets, see here.
Does liquibase guarantee, that the changes are executed sequentially in the order that they appear?
I've never saw any documentation about it, but in my experience - it does execute changes inside the changeSet sequentially in the order they appear.
Also, I don't think it's good practice to put all the above changes into one changeSet, because, as stated in the document you've provided:
Liquibase attempts to execute each changeSet in a transaction that is committed at the end, or rolled back if there is an error. Some databases will auto-commit statements which interferes with this transaction setup and could lead to an unexpected database state. Therefore, it is usually best to have just one change per changeSet unless there is a group of non-auto-committing changes that you want applied as a transaction such as inserting data.
I suggest separating your changeSet into three atomic ones with appropriate preConditions, or create a proper rollback for it.
In our build server, we have a number of feature branches get deployed against one database. The problem is sometimes some buggy scripts in one branch causes LB to exit without releasing the lock. The problem is there is no easy way to find out what branch caused this. We may have up to 30 branches getting deployed constantly as there are new changes against the branch.
Is there any way (or can we have new feature in Liquibase) to set the instance name and the name can be stored in LOCKEDBY column of table DATABASECHANGELOGLOCK so we can easily find out what branch/instance caused the issue?
Currently, LOCKEDBY has only IP in it which is the same for all the instances.
You can specify a system property which gets insert into the LOCKEDBY column:
System.setProperty("liquibase.hostDescription", "some value");
I think to achive this you need to patch Liquibase somewhere here:
https://github.com/liquibase/liquibase/blob/ed4bd55c36f52980a43f1ac2c7ce8f819e606e38/liquibase-core/src/main/java/liquibase/lockservice/DatabaseChangeLogLock.java
https://github.com/liquibase/liquibase/blob/ed4bd55c36f52980a43f1ac2c7ce8f819e606e38/liquibase-core/src/main/java/liquibase/lockservice/StandardLockService.java
to fetch additional variable somehow (property file/env variable/etc) and store in the table.
Btw, be careful with deploying multiple branches with the same database instance, because it is possible that you will make a change in DB structure for one branch, that will break another one.
Liquibase ask for fully defined schema Name, for example for the indexExists tag. But what if want to run a changeset on multiple schema. Is there a way to indicate running on the current schema, or to dynamically set it when running an update ?
My Bad, that schemaName is not a required attribute for createIndex.
In our case liquibase is used to update databses for existing installation. New installations are already up to date.
Assuming we have got a new installation. Starting the application will force to execute liquibase changesets (e.g. change type of a column) but as I mentioned before there is nothing to update as the column already was created with the correct type.
Does liquibase recognize that the table column is already up to date or does it try to execute the changeset as there is no entry within the databasechangelog table for it?
Liquibase uses an alternative approach that avoids a need to analyze the target database's data dictionary. This makes DB operations simpler and more cross platform.
A special table "DATABASECHANGELOG" keeps a record of the changesets applied to the target database instance. This table also contains a checksum (calculated at runtime) to determine if changsets are altered between runs of liquibase.
So if you altered the type of a table column, liquibase can detect this and can throw an error, when run against an existing database. (Obviously, on a new DB, the table would be created as expected).
Finally, the changeset documentation describes two optional attributes ("runAlways" and "runOnChange") which could tell lqiuibase to reapply a changeset more than once to a database. There is also a "clearCheckSums" command that can be used to reset the checksums on an existing database. Obviously you need to know what you're doing when using such an option :-)
Liquibase will not recognize anything automatically.
But you can use <preConditions/> in your changeSet to check if your changeSet must be applied or not.