My understanding is that will just give me a boolean that a object exists or doesn’t, it won’t actually let me say if false please go and execute script xyz.sql as part of the normal liquibase build process.
The difference is with the new approach is the dependencies you list should be executed for you if it hasn’t already been executed. For example currently if I have three tables animal, classification, animal_classification and my liquibase config is setup to point to a directory called /tables with a script for each table in a raw sql file liquibase will grab animal then animal_classification followed by classification and fail because of the fks on animal_classification depending on animal and classification . The desired order should be animal, classification, and then animal_classification. Under the new approach I would list the dependencies in the animal_classification sql script. Something like --dependsOn animal.sql, classification.sql also these could be stored procedures, views, index etc etc not just tables.
Imagine you have a existing database with 1,800 tables, 4,000 stored procedures, hundreds of view yadayada how do propose you script out your existing database and build a clean empty database for development with liquibase without getting hundreds if not thousands of dependency error messages. In the database order matters or else you can’t execute your scripts. Now I don’t mind creating my own process that scripts out my existing structure and adds the tag dependencies that I described. I just want liquibase to be able to read this tag data and run the scripts in that order. This allows me to still name my scripts the same as the object name and not have to create a hodge-podge of liquibse config files to mimic this behavior.
If I’m missing something please let me know I would love to be wrong on this.