feat: add customizable lock value#1403
Conversation
zsalzbank
changed the title
|
Fixed the formatting issue. Is that why it was assigned back to me? Is there something else I should be doing? Thanks! |
No, I usually assign the accounts to the PRs, so I can filter in the PR list overview. |
Shinigami92
left a comment
Shinigami92
left a comment
There was a problem hiding this comment.
we definitely need to add a test somehow 🤔
maybe in .github/workflows/postgres-test.yml and/or in test/runner.spec.ts
| Migration, | ||
| runner as migrationRunner, | ||
| PG_MIGRATE_LOCK_ID, | ||
| } from 'node-pg-migrate'; |
There was a problem hiding this comment.
thought: I'm not sure what's going on here, when I try to run everything locally and rebuild everything it works
There was a problem hiding this comment.
it seems rebasing got rid of the links to the old action runs
I think I had to do this because when I added an import to the file that contains the constant directly, the src was not converted to dist, so it failed to import
|
Please also rebase the PR |
zsalzbank
force-pushed
the
add-custom-lock-value
branch
from
489465d to
b26f1e6
Compare
|
@zsalzbank please hit rebase/update branch |
|
thanks! |
2 participants
I have a couple of separate migration directories in the same repository and when I need to, I run the migrations from a specific directory. The migrations all run on the same database, but for different schemas.
If two migration directories run at the same time (but still in separate processes), there is a slight chance that the lock of one directory blocks the migration of the other directory.
To avoid this, I've introduced a
lock-valueargument to the runner options. This allows customizing the value that is used for the lock from the command line.I didn't really see any tests for the locking mechanism anywhere, so I didn't add any to this PR, but I'm happy to if you let me know where you'd like them.