[GitHub] [superset] CraigChaffee commented on issue #14053: Superset becomes unresponsive if a database is not responding

[GitBox <gi...@apache.org>]

CraigChaffee commented on issue #14053:
URL: https://github.com/apache/superset/issues/14053#issuecomment-818289226


   I dealt with this directly. From what I can tell several operations fail or take unnecessarily long if a db connection fails when they definitely shouldn't. This behavior multiplied the complexity and extent of an otherwise simple outage blocking access for all users on all other DBs.
   
   When a database connection takes a long time to respond we've seen the following endpoints also timeout:
   
   List databases api /api/v1/database/ (breaks sql lab)
   List Databases page /databaseview/list/
   Database Edit/Save
   
   It's not clear why any one of these pages would need to verify all connections before loading data. I haven't dived into the code, but this seems like a major design flaw. During our outage there was no way to debug or modify anything through the web interface. What's worse is that by design Superset doesn't allow deletion of entities whenever there are dependent tables (delete on cascade) so dealing with the permanent deletion of any database is colossally painful. Anyone who has tried to delete and been blocked by a maze of foreign key constraints. I realise not cascading on delete is safer, but not allowing a safe way to do this makes administration unreasonably cumbersome.
   


-- 
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:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org