half-working changesets not treated atomically

General Discussion
1

If you run a half-broken changeset (e.g. a single changeset with two refactorings one of which has an error), the working part of the changeset will be applied and the broken part will fail.  The changelog will not be updated, so future runs will try to rerun changeset, but fail because the working part is already applied.


I would think it would treat a changeset atomically, and roll it back if it was not able to complete it – the following changeset causes this behavior:


  2. <?xml version="1.0" encoding="UTF-8"?>

  4. <databaseChangeLog
  5.   xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
  6.   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  7.   xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
  8.          http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd">


  12.      
  13.          
  14.      
  15.      
  16.      
  17.          
  18.      

The resulting table has the working column, but not the notworking column, and will fail every time afterward, even when corrected, because the working part of the changeset was already applied.
2

Liquibase tries to run each changeSet in a transaction (including the insert into databasechangelog) but the trouble is that on many databases DML statements like alter table are auto-committing and there is nothing we can do about that.


It depends on the database, but a good rule of thumb is that any changes except insert/update/delete commands should be in their own changesets.


Nathan

3

Fair enough re: DDLs, I will bear in mind your rule of thumb.


I tried a similar scenario (below) with just DML statements and it behaved as expected - a changeset with one working insert and one failing will result in no records being inserted – thanks!


  3.     ID is primary key.  Username is unique.  This will violate the PK constraint.