eschutho edited a comment on issue #12566: URL: https://github.com/apache/superset/issues/12566#issuecomment-769300915
>When discussing database migrations, the main consideration mentioned here is "time to run", but it doesn't address backwards compatibility of database migrations or push safety of db migrations. I'd recommend some additional guidelines for non-major changes: > Columns should not be renamed, and instead a new column with a new name should be added. An additional migration can remove the now unused column once all references to it are removed from code in a future release Columns should not be deleted, unless all references to it are removed from code in a previous release This is mainly to ensure that when deploying db migrations in non-major versions, it can be done so without any downtime @etr2460 I agree. I think it would be safest to also add that any migrations that drop a table or column should be in the major release version, in case people bump two minors at once. Even if people skip a minor version and go straight to the major, they'll still run into the same downtime issues. Therefore I'd also recommend that if there is a destructive db migration in a major version we encourage people to upgrade at least to the last minor version, run the migrations, and then upgrade to the major version. Do you think that's doable? I updated the doc with the recommendations if you would like to see the suggestion I proposed. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
