Closed bomoko closed 6 months ago
I don't think a "down" is required for this particular migration, it is fixing a problem that should have been this way from the start. How would you come back from this, the projects don't exist anymore?
I agree, this is what I'm implying as well. Assuming that the "down"'s job is to get the DB in the same state it was in before running the migration up, then essentially you'd be wanting to update those (and only those) items targeted by the up migration and set them back to "0000-00-00 00:00:00", right?
This is why I thought something like setting the deleted
datetime to something very specific (and not natural) would be one way of rolling back the change (there are other ways, of course).
I don't think that it's necessary, though - which is why I didn't supply an implementation! I just wanted to not that I didn't, and make sure nobody had any issues with that :)
I say, migrate:up with impunity!
As discussed in #3630 there are cases in previous versions of Lagoon where projects have been deleted and have had their environments orphaned without the (the envs) having their
deleted
field set to a non-zero/default value.This PR introduces a migration to set the
deleted
field to the current date/time to mark an environment as having been deleted.Note: there is no "down" specified for this migration - I wasn't sure what we wanted to do here. It's obviously not best to just simply reset all orphaned items
deleted
field to 0, since that's not the state of the DB pre migration (or, isn't guaranteed to be).One option, I suppose, would be to set the date/time to something very specific - like "0000-00-01 11:11:11" -- assuming that this value wouldn't arise "naturally" -- and then have the down migration target environments with that date/time? Thoughts?
General Checklist
Database Migrations