liquibase / liquipy Goto Github PK

Use python logging instead of print statements; but don't initialize logging -- logging initialization/configuration should be done by the app that's using liquipy

Need to test:

• ChangeSets are executed in the expected order
• Previously-executed changesets are not re-executed
• Newly-added, previously un-executed ChangeSets are executed
• Duplicate ChangeSet identifier numbers are detected and the expected exception is raised (this can be a unit test instead of integration test)
• Rollback works as expected
• User-passed tempDir in LiquipyDatabase versus default tempDir handling
• Failures in liquibase are propagated as approprirate exceptions.
• etc.

Several instances in https://github.com/GrokSolutions/liquipy/blob/master/liquipy/changeset.py which require a rollback migration. A rollback migration should be optional in liquipy if, for example, as an organization, the user decides to not implement rollbacks and enforce a forward-only migration path.

When I run update multiple times, liquibase complains that those tables already exist: "Table 'metric_template' already exists", etc. and exits with non-zero code. I would have hoped that since liquibase records the tags, it wouldn't execute the same changeset again.

I came across a liquibase discussion http://forum.liquibase.org/topic/why-does-the-change-log-contain-the-file-name that most likely points to a serious bug in liquipy and explains the reason that my changeset is getting executed over and over: it's because liquibase saves the changelog xml file path in the FILENAME column of the DATABASECHANGELOG table and uses that FILENAME value (in addition to ID and MD5SUM) to uniquily identify the changeset. Liquibase assumes that this path never changes. However, liquipy's behavior conflicts with that assumption: liquipy generates the changelog xml file from YML files and the generated XML file is placed in a temporary directory (in any case, those generated files cannot be preserved indefinitely) e.g., /var/folders/kn/xpy4z9wx001_zwmfyzcgxcg40000gp/T/tmpZn5NU_/liquipy_changelog.xml. Thus, the file path is different each time liquipy-based update is exected, so liquibase keeps re-executing the changesets over and over again.

From the discussion at http://forum.liquibase.org/topic/why-does-the-change-log-contain-the-file-name, it seems that logicalFilePath may be used by liquipy to solve this problem. liquipy could hard-code logicalFilePath to something like liquipy_changelog.xml in the generated XML file and never change it.

A lot of fixes since 3.0.4: https://github.com/liquibase/liquibase/blob/master/changelog.txt

Add validation code in inputYamlToChangeSets() to make sure that the same changeset ID is not used in different YMLs. ID re-use should raise an exception.