Re:Ask HN: Has anyone migrated off containerized infrastruct...
by jlangenauer on Friday August 14, 2020 @10:46AM
(#24158577)
My solution to this is to rename that table/column to “table_deprecated” or “column_deprecated”. This has the nice property of being reversible, causes nice visible errors if something unanticipated is actually using the column/table, makes it obvious that it shouldn’t be used (well, one would hope), and makes it easy to find for permanent deletion later.
[ Parent
| on HN ]
Re:Ask HN: Has anyone migrated off containerized infrastruct...
by freedomben on Friday August 14, 2020 @10:59AM
(#24158758)
That's a great idea! Although I did work with a person once who would use anything that looked helpful regardless of "deprecated" being all over the place (Eclipse would even yell at the method calls but he didn't care). Granted that's Java and at that point in time APIs were being deprecated without workable replacements, so it's hard to fault him.
Re:Ask HN: Has anyone migrated off containerized infrastruct...
by symlinkk on Friday August 14, 2020 @11:14AM
(#24158969)
At that point you might as well just delete them.
Re:Ask HN: Has anyone migrated off containerized infrastruct...
by mike-cardwell on Friday August 14, 2020 @12:01PM
(#24159655)
I think you're missing the point. If your migration renames a table or column, then the migration can be rolled back, by simply reversing the rename. If you delete the thing, then there is no way of rolling back other than restoring from backup.
I can see it being useful to rename these things, as long as there is some process in place to delete the renamed items after a period of time has passed.
Would be good if you could schedule a future migration that will happen only after a certain date has passed, which deletes the renamed tables/columns.