-
Notifications
You must be signed in to change notification settings - Fork 13.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate database attribute allow_run_sync #4961
Deprecate database attribute allow_run_sync #4961
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4961 +/- ##
==========================================
- Coverage 73.36% 73.35% -0.01%
==========================================
Files 67 67
Lines 9584 9582 -2
==========================================
- Hits 7031 7029 -2
Misses 2553 2553
Continue to review full report at Codecov.
|
Thanks for simplifying this logic. One concern is that we shouldn't augment existing migrations but simply create a new migration which drops the deprecated column and sets the async value appropriately. |
@john-bodley this was done on purpose as db migrations have been a huge plague and should be avoided whenever possible. A lot of the downtime in the history of Superset has been related to db migrations. Either, db locks/deadlocks at migration time, partial rollout (some in-deployments nodes are missing the new column, deployment reverts requiring a manual downgrade from the previous branch, ...) The lingering database column in my opinion is no big deal in comparison to the issues related to db migrations problems. |
PING |
12252ad
to
1d57188
Compare
1d57188
to
cdc170a
Compare
@john-bodley @timifasubaa reviving this, and added the db migration to keep the db clean |
Looks good to me once you get it to pass CI |
d1dc070
to
bb0d081
Compare
There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it.
7564632
to
f31add1
Compare
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
* Deprecate database attribute allow_run_sync There's really 2 modes of operations in SQL Lab, sync or async though currently there are 2 boolean flags: allow_run_sync and allow_run_async, leading to 4 potential combinations, only 2 of which actually makes sense. The original vision is that we'd expose the choice to users and they would decide which `Run` or `Run Async` button to hit. Later on we decided to have a single button and for each database to be either sync or async. This PR cleans up allow_run_sync by removing references to it. * Fix build * Add db migration * using batch_op (cherry picked from commit 2931baa) (cherry picked from commit d07786e)
There's really 2 modes of operations in SQL Lab, sync or async
though currently there are 2 boolean flags: allow_run_sync and
allow_run_async, leading to 4 potential combinations, only 2 of which
actually makes sense.
The original vision is that we'd expose the choice to users and they
would decide which
Run
orRun Async
button to hit.Later on we decided to have a
single button and for each database to be either sync or async.
This PR cleans up allow_run_sync by removing references to it.