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

Locking migrations #88

Merged
merged 2 commits into from
May 25, 2017
Merged

Locking migrations #88

merged 2 commits into from
May 25, 2017

Conversation

dolezel
Copy link
Contributor

@dolezel dolezel commented May 23, 2017

Fixes #72
I found several options:

  • lock migration table - it is not doable because it needs to be wrapped in transaction and we are (optionally) locking each migration in transaction and it can be switched off because some DDL can't be in transaction
  • using Shared data but it needs python extension installed and it can be done only with administrator rights
  • using temporal tables - it also needs to have extension installed
  • using extra table - it have benefit that it can store some additional info and it can check and set lock in one command (aka UPDATE/INSERT INTO xxx WHERE lock IS NULL) but I do not want to pollute schema with another table
  • maybe there are other options but it will be probably roughly same as using comment on table I decided to use.

@dolezel dolezel requested a review from roman-kaspar May 23, 2017 10:57
@dolezel dolezel force-pushed the locking branch 3 times, most recently from 308eea3 to 21e1520 Compare May 23, 2017 11:07
lib/runner.js Outdated
.then(() => db.query(`COMMENT ON TABLE "${schema}"."${options.migrations_table}" IS '${lockName}'`))
.then(getCurrentLockName)
.then(currentLockName => {
if (currentLockName !== lockName) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now when I'm looking on it. It is not 100% lock 🤦‍♂️
When some other lock manages to run between first getCurrentLockName and commenting on table, we will have two locks obtained...

lib/utils.js Outdated

export const getMigrationTableSchema = options => options.migrations_schema || options.schema || 'public';

export const finallyPromise = block => [
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately native Promise does not have finally...


export const getMigrationTableSchema = options => options.migrations_schema || options.schema || 'public';

export const finallyPromise = func => [
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately native Promise does not have finally...

Copy link

@roman-kaspar roman-kaspar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dolezel dolezel merged commit d7d5b15 into master May 25, 2017
@dolezel dolezel deleted the locking branch May 25, 2017 08:49
@dolezel dolezel changed the title Locking migrtions Locking migrations May 25, 2017
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

Successfully merging this pull request may close these issues.

2 participants