-
Notifications
You must be signed in to change notification settings - Fork 14k
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
Allow overwriting a SQLLab query that has previously been saved #8298
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments and some red on the builds, otherwise LGTM
There's one cypress test that failed in that last build, but I can't reproduce it on my machine. It's probably flaky. If someone with the necessary auth could re-run that job it'd be much appreciated. |
I restarted the build, I believe this is due to flakiness. |
Codecov Report
@@ Coverage Diff @@
## master #8298 +/- ##
==========================================
- Coverage 73.53% 67.76% -5.78%
==========================================
Files 115 451 +336
Lines 12396 22730 +10334
Branches 0 2377 +2377
==========================================
+ Hits 9116 15402 +6286
- Misses 3280 7190 +3910
- Partials 0 138 +138
Continue to review full report at Codecov.
|
@suddjian this PR broke existed save query feature. when i try to save a query from sql lab, i got server-side error message: |
Thanks for the report @graceguo-supercat I could have sworn I saw this working! I am able to repro it though, so hopefully I'll have a fix up today. |
…ed (apache#8298)" This reverts commit fbbc5f0.
…ed (apache#8298)" This reverts commit 3aa3da9.
CATEGORY
Choose one
SUMMARY
When saving a query in SQLLab, currently there is no good way to update a query you were previously working on. You have to save a new one, then go to the saved queries list and delete the old one. This change lets you choose to overwrite the previous entry or save a new copy.
A speed bump I ran into was that the frontend is using several field names that are different from the names the backend uses. My first instinct was to change that so that a field means the same thing everywhere, but that gets pretty complicated pretty fast, due to the way the redux state is being persisted locally - how does the Superset frontend do migrations? #7748 will probably allow solving this problem.
So instead I grouped the existing differences (plus my addition of a
remoteId
field) into aqueryClientMapping
object, with the goal of isolating the differences to one layer of the system - where the client actually makes API calls. That way UI components likeSaveQuery
don't have to concern themselves with those differences. This hasn't been propagated to all parts of the code that use saved queries, yet.BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before:
After:
TEST PLAN
I've already tested it pretty well, I think. This is my first contribution to Superset so it's entirely possible that I missed something. It would be nice to get some additional verification that nothing I've done will mess up anyone's local state.
ADDITIONAL INFORMATION
REVIEWERS