search

yogthos / migratus

MIGRATE ALL THE THINGS!
651 stars 95 forks source link

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

Open sirmspencer opened 1 year ago

sirmspencer commented 1 year ago

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.

yogthos commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

(mig/migrate {:to :now})

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

??

sirmspencer commented 1 year ago

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

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

yogthos commented 1 year ago

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

sirmspencer commented 1 year ago

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 commented 1 year ago

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

sirmspencer commented 1 year ago

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

Perfect. That is what I was thinking too.