betodealmeida commented on pull request #11098: URL: https://github.com/apache/incubator-superset/pull/11098#issuecomment-700422449
> One problem with db migrations is that they cannot be cherry-picked out of order. Or they can if they both reference the same parent and ultimately need a converging migration. All this is fairly confusing. Less migrations is probably better. Either way I'd advise release managers to avoid cherry-picking anything with a migration. Right. The case I was thinking of was when you want to cherry-pick feature `B`, and it has a database migration `Mb` that comes after another migration `Ma` that also needs to be cherry-picked. If the PR implementing `Ma` and the feature `A` is big it's harder to cherry-pick it, but you're forced to do it because of the Alembic DAG. If instead you separate the feature `A` into one PR, and the migration `Ma` into another, someone interested in cherry-picking feature `B` can just cherry-pick the actual migration `Ma` and skip the PR implementing `A`, assuming that the DB migration is non-disruptive — eg, adding a column like we're doing here. But in this case it doesn't matter, because the migration changing `position_json` is disruptive, and can't be separated from the changes in the logic to read the new schema. So I'll go ahead and implement the migration of `position_json` in this PR to consolidate the migrations. Thanks, Max! ---------------------------------------------------------------- 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]
