You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 28, 2024. It is now read-only.
Uncomment the second changeset and run again.
=> Change Set scripts/databaseChangeLog.yml::1::test failed. Error: ERROR: schema "test" already exists [Failed SQL: create schema test]
The problem is the statement liquibase.dropAll(), which only deletes the default (public) schema.
There are multiple solutions to this:
Never reuse a container, instead create a new one every time (and delete it afterwards).
Add plugin configuration options for schemas to be deleted in Liquibase.
Never delete the database in an existing container, but instead add a task to delete the container from Gradle.
Personally I think the first solution is the easiest with least risk of future headache. There might be a slight performance impact, but since the plugin only runs when there are actual changes to the changelog this might not be such an issue.
The text was updated successfully, but these errors were encountered:
Follow up: I spent some time trying to implement the schema migrations. It seems to be trickier that just passing along another parameter to the Flyway, and Liquibase instances.. (see here.
I think I will implement forced container recreation as soon as I find the time to do so.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When running migrations with Liquibase, Postgres and multiple schemas, the database is not properly cleaned up after each run.
Reproduction steps:
=> Change Set scripts/databaseChangeLog.yml::1::test failed. Error: ERROR: schema "test" already exists [Failed SQL: create schema test]
The problem is the statement
liquibase.dropAll()
, which only deletes the default (public) schema.There are multiple solutions to this:
Personally I think the first solution is the easiest with least risk of future headache. There might be a slight performance impact, but since the plugin only runs when there are actual changes to the changelog this might not be such an issue.
The text was updated successfully, but these errors were encountered: