<span.
That way, the database update would not fail, if the same change has been already applied without using liquibase. The resulting schema should be the same, the changeset should be marked as executed.
Do you think, this would be a useful improvement to be integrated into liquibase?
Regards,
Andreas
This is actually very similar to functionality I just started adding. I’m experimenting with adding verifyUpdate, verifyUpdateDetails, verifyRollback and verifyRollbackDetails methods to each of the change implementations with logic on how to check them. The difference between the *Details and non-details methods is that the regular method checks , for example, that a column was added while the *Details methods check all the other attributes like the data type, if it is a primary key, etc.
I am implementing it within java rather than SQL, where I use the snapshot function to grab the state of the object to check and then inspect it. The reason for this is it gives us more flexibility than what is available through SQL, but it has the limitation that we cannot embed the checks into updateSQL for example.
My initial use for the methods is for automated generative testing of change implemenations, but I see a lot of other advantages such as being able to run an update with automatic “did it run” checks, easier bootstrapping of an existing project, and more. I’m hoping to have it finished up next week and will have a pull request for people to look at.
Nathan
This is great news!
I think, this will also change, how my other pull request is implemented: https://github.com/liquibase/liquibase/pull/260
Let me know, if I can help you.
Regards,
Andreas
