It appears that preconditions can only check the state of the database as it existed at the beginning of the Liquibase run. Is that on purpose?
For example, suppose we have the following sequence:
- transactional changeset: createTable A
- transactional changeset: check to see if A exists () and add a column
On the first run, the precondition guarding the second changeset will not detect that table A exists, correct?
Is that a flaw, or a deliberate design decision?
Best,
Laird
–
http://about.me/lairdnelson
I believe we are seeing this on Liquibase 2.0.1 (we have to use this as after this version Informix support stopped working; PRIMARY KEY clauses are appended to almost every fragment of DDL) when run against (at least) SQL Server. The precondition in question is . I’m working off an anecdotal report at the moment so I will need to check back with the developer in question.
Thanks,
Best,
Laird
–
http://about.me/lairdnelson
The changeSet level preconditions should be checking the state at the time the changeSet runs, not from the beginning, so in your scenario changeset 2 will see that table A exists, even in the first run.
Are you seeing differently? And what version are you running?
Nathan
Actually, it turns out that CORE-837 is not fixed; on Liquibase 2.0.1 on SQL Server does not work.
Thanks,
Best,
Laird
–
http://about.me/lairdnelson