Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Postgresql) Migration applied if the update of the schemaversion table throws an error #110

Open
p16 opened this issue Jun 19, 2020 · 1 comment

Comments

@p16
Copy link

p16 commented Jun 19, 2020

Hi,
I'm running postgrator with postgresql and I found a potential issue when the insert into the schemaversion table fails.

  1. A migration is run and changes the db
  2. The insert fails to update the schemaversion table

I would expect the whole migration to "rollback" but instead I see the migration changes applied and the schemaversion table still pointing to the previous migration as its latest one.

This will cause an error if migrations are run again and they are not idempotent.

I have a branch with a test reproducing this scenario here .

I'm wondering if this scenario is a known edge case and the only solution would be to write idempotent migrations, or if postgrator could support the scenario where both migration and insert are guaranteed to be either "done" or "not done".

@p16 p16 changed the title (Postgreql) Migration applied if the update of the schemaversion table throws an error (Postgresql) Migration applied if the update of the schemaversion table throws an error Jun 19, 2020
@rickbergfalk
Copy link
Owner

This is a known edge case but it should probably be documented.

I'd really like to wrap the whole migration in a transaction (including persisting the schema version) but there are complications with that especially when trying to support multiple databases. While Postgres supports DDL in a transaction, MySQL does not for example. And even with Postgres, some things like creating an index concurrently cannot be done within a transaction.

I'm open to PRs if anyone has any ideas on how to handle this too.

Something I've thought of is to run the down migration if the insert to schemaversion fails to undo what was done, but there's no guarantee that succeeds either.

Writing idempotent migrations is probably the most practical solution to all of this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants