Bacpac file + migration

I have a question about running my migration scripts against an existing database.

Our DBA team created a bacpac file of our dev database. In my testing, I take that file and import it to create a database locally that matched our dev dB. This dev dB has already had our migration scripts run against it. I was hoping that I could run liquibase against that database, and it would only run scripts that had not been run already (as it does when running from scratch). Is there a way to update the database so that liquibase knows that those scripts have already been run?

And…answering my own question. I didn’t notice at first but the filename that was stored in the databasechangelog table had a slightly different path. So I guess the md5 hash generated was slightly different. Will have to look into how I can keep it the same.

1 Like

So my new question now is:

the path in my changelog.xml had
<includeAll path="..\Migrations\Tables" relativeToChangelogFile="true"/>

In the DATABASECHANGELOG table, the files were all saved with a prepended ‘…/Migrations/Tables…’
However, when I run the same migration now, with the same changelog.xml file, the …/ is no longer in the ‘filename’ column in the dB. Is this due to some change in the way liquibase stores the filename? (the original table was generated using a very old 3.5.3 version), but I’m using the 4.11 version.

I’ll update the column to match the expectation if that’s the way it is, but I wouldn’t want to change it if I’m doing something unusual in my file references.

I have done some more testing with this, and there does seem to have been some sort of change from 4.10 → 4.11. Using multiple versions of docker (started with 4.6, progressing to 4.11), 4.6 - 4.10 all saved to the log, starting with an empty dB, like this ./changelog/../Migrations/Tables/20200616.01-DocumentTable.sql Then it also tried to run the scripts a second time and the blew up stating that the table already exists (which it would as it had already created it on a previous run).

This appeared to be fixed in 4.11 (as it was not doing either the double run, or adding the ./changelog/.. in front of everything, but I was just hoping for some confirmation in case I’m doing something wrong.

The command is running with these params
url=jdbc:sqlserver://${SQL_SERVER_URL};database=${DATABASE_NAME};username=${DB_LOGIN};password=${DB_PASSWORD};${EXTENDED_CONNECTION_PROPERTIES} --changelogFile=./changelog/changelog.xml update

And the location of everything is just

  • .\liquibase:/liquibase/changelog
  • .\Migrations:/liquibase/Migrations`

So nothing crazy there either, I don’t think. I tried adjusting the location of the changelog file to see if that made a difference, but it did not seem to.

I just verified in 4.12 and that mimics the functionality in 4.11.