Vitor-Avila commented on PR #32043: URL: https://github.com/apache/superset/pull/32043#issuecomment-2624981064
> @Vitor-Avila if these migrations are optional, why are they executed by default in the first place? Isn't better to just remove them from the upgrade script instead of create a new feature flag? If they are not optional, what happens when they are skipped because of the feature flag? Hey @michael-s-molina, Before catalogs, to query something from another database in the DB instance/host users would have to do it via a virtual dataset using `select * from <other_catalog>.<schema>.<table>`. These "secondary permissions" are created so that after the migration, limited users need access on these other catalogs in order to query them in SQL Lab. For existing datasets and charts, they'll all be associated with the `default_catalog` in their permission setting (even if they're querying other catalog) as we won't parse the query to determine (the same happens today if you create a dataset with `schema_a` selected in the dropdown and use `select * from schema_b.table`). That said, ideally creating these permissions during the migration is a good thing, but we've seen cases where this process takes too long, and that causes a very long migration/downtime. For example, there used to be a Postgres Cloud service named `ElephantSQL`, and your credentials would be able to list all DBs in the instance (even though you actually don't have access to these other DBs). These permissions are going to be added by the time you edit the DB configuration (either to enable the ability to change catalogs, or any other change actually). I thought about adding it as a config because if you're able to run the migration with the config disabled, then it's great! All perms created. But if you start facing issues, a long downtime, then enabling the setting might be ideal. Let me know your thoughts. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
