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

Allow for future migrations that are not run until the timestamp on the migration has passed #243

Open
sirmspencer opened this issue Jun 20, 2023 · 10 comments

Comments

@sirmspencer
Copy link

Add an optional input to migratus/create that sets the date X days in the future, and then update migratus/migrate to skip those.

The use case is for when the table structure changes so that there is an old table or column that needs to be cleaned up. This would let me create that clean up for 30 days when I know all the other code changes have taken place.

@sirmspencer sirmspencer changed the title Don't run migrations set in the future Allow for future migrations that are not run until the timestamp on the migration has passed Jun 20, 2023
@yogthos
Copy link
Owner

yogthos commented Jun 20, 2023

That sounds like it would be a reasonable idea. Should be easy enough to pass an additional flag for this and then filter against it when selecting the migrations to run.

@sirmspencer
Copy link
Author

I can take care of it. Do you want two flags? 1 for migratus/create to generate the future timestamp, and 1 for migratus/migrate to skip future migrations?

@yogthos
Copy link
Owner

yogthos commented Jun 20, 2023

Sounds great, and that would make sense, maybe create could take an additional argument to specify the start time explicitly then and if it's provided use that instead of generating the timestamp.

@sirmspencer
Copy link
Author

Sounds great, and that would make sense, maybe create could take an additional argument to specify the start time explicitly then and if it's provided use that instead of generating the timestamp.

For which of the functions?

@sirmspencer
Copy link
Author

sirmspencer commented Jun 20, 2023

(mig/create {:future-days 30} title :edn)

(mig/migrate {:to :now})

(mig/migrate {:to "20230526202953"})

??

@sirmspencer
Copy link
Author

This could be added later, but I wouldn't do it in this pr.

(mig/rollback {:to "20230526202953"})

@yogthos
Copy link
Owner

yogthos commented Jun 20, 2023

Yeah, I think human readable format would be ideal here for create. :) And migrate to :now or explicit timestamp sounds good.

@sirmspencer
Copy link
Author

Default to :now or not? Its bordering on breaking, but I would also guess that with mig/create, no one is making future dates manually.

@yogthos
Copy link
Owner

yogthos commented Jun 20, 2023

I think defaulting to :now would be reasonable, that's basically the implicit behavior right now.

@sirmspencer
Copy link
Author

I think defaulting to :now would be reasonable, that's basically the implicit behavior right now.

Perfect. That is what I was thinking too.

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

No branches or pull requests

2 participants