-
-
Notifications
You must be signed in to change notification settings - Fork 95
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
Comments
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. |
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? |
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? |
?? |
This could be added later, but I wouldn't do it in this pr.
|
Yeah, I think human readable format would be ideal here for create. :) And migrate to |
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. |
I think defaulting to |
Perfect. That is what I was thinking too. |
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.
The text was updated successfully, but these errors were encountered: