-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add migration lifecycle hooks #5541
Add migration lifecycle hooks #5541
Conversation
if (commitFn) { | ||
commitFn(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the explicit commit so that we can run the afterEach
hook in the same transaction (line 527)
@kibertoad gentle ping - would love to get your feedback on this 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! thanks for the great job!
could you please also update the types?
left few comments and I also think docs should be updated as well (Cc @kibertoad)
Also few questions:
- If you have 2 migrations, and the second one failed, should you run the
afterAll
should you rollback thebeforeAll
? - In case transaction are disabled for migrations, should we allow hooks?
…-migration-lifecycle-hooks
test/integration2/migrate/migration-lifecycle-integration.spec.js
Outdated
Show resolved
Hide resolved
In this scenario, I feel like it may be appropriate to abandon the afterAll and roll back the beforeAll.
I can't personally think of a situation in which someone would want to run these hooks without also running their migrations in a transaction, though I wouldn't be surprised if that's a use case for someone out there. Maybe for the initial release, we can require transactions to run hooks, and see if anyone raises an issue with that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add test when transaction are disabled for migration? And also update the types
test/integration2/migrate/migration-lifecycle-integration.spec.js
Outdated
Show resolved
Hide resolved
test/integration2/migrate/migration-lifecycle-integration.spec.js
Outdated
Show resolved
Hide resolved
|
||
// Force clean slate before each test | ||
beforeEach(async () => { | ||
rimraf.sync(path.join(__dirname, './migration')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why sync?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not 100% sure - this setup block was copied from migration-integration.spec.js
and I chose not to change anything.
Co-authored-by: Raz Luvaton <16746759+rluvaton@users.noreply.github.com>
….com:leaselock/knex into timorthi/issue2983-migration-lifecycle-hooks
name | ||
); | ||
return await this.knex.transaction(async (trx) => { | ||
await beforeEach(trx, [migration]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The migration that's passed into the hook is wrapped in an array here to maintain consistent types between the each
and all
hooks (instead of passing in an array in all
but a migration object in each
)
|
||
// Force clean slate before each test | ||
beforeEach(async () => { | ||
rimraf.sync(path.join(__dirname, './migration')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not 100% sure - this setup block was copied from migration-integration.spec.js
and I chose not to change anything.
I took a closer look at the code and it appears that the user is allowed to customize whether each migration is run in a transaction or not: knex/lib/migrations/migrate/Migrator.js Lines 480 to 490 in f7a3147
Because of this, I think it may be simpler to just run the lifecycle hooks all the time, even if transactions are disabled. Otherwise, we will be dealing with a bunch of edge cases regarding when or when not to run lifecycle hooks. What do you think and would you still like me to test the non-transaction case if we choose to always run hooks? |
Can you please update the types and fix the CI so we can merge this |
@rluvaton I've updated For CI, it looks like this particular step (Legacy Types Linting) has been failing for the last 3 weeks, unrelated to this PR https://github.com/knex/knex/actions/workflows/linting-legacy.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution
@kibertoad LGTM
Please can this be merged? I need this as well. |
Hello and thank you all for your contribution! I really needed this feature. I noticed that the change has been merged into master but I see that a new version hasn't been pubilshed to npm. Thanks a lot! |
This is an attempt at addressing the use cases described in #2983 .
This adds the ability for the user to define a
beforeAll
,afterAll
,beforeEach
,afterEach
hook during migrations.