Skip to content
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

Better distinction between tables and views, and show CREATE VIEW #8213

Merged
merged 11 commits into from
Sep 17, 2019

Conversation

betodealmeida
Copy link
Member

CATEGORY

Choose one

  • Bug Fix
  • Enhancement (new features, refinement)
  • Refactor
  • Add tests
  • Build / Development Environment
  • Documentation

SUMMARY

In SQL Lab, to distinguish between tables and views we prefix the latter with the string [view], which looks ugly. I changed it to display a small icon representing the type — either a table for actual tables, or an eye for views.

Additionally, we don't present any information on views. I added a link to show the actual CREATE VIEW statement that defines a given view.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Screen Shot 2019-09-10 at 1 53 44 PM

Screen Shot 2019-09-10 at 1 54 03 PM

Screen Shot 2019-09-10 at 1 54 09 PM

TEST PLAN

Currently most DB engine specs seem to return views as tables, due to limitations in the SQL Alchemy driver. Both Presto and SQLlite return no views, bundling the views with the actual tables. I had to mock the response from the engines to generate the screenshots.

I'm planning to write a PR for Presto next, allowing views to be properly displayed. This might require changes upstream (to https://github.com/dropbox/PyHive), though it's possible to work around it in Superset only.

ADDITIONAL INFORMATION

  • Has associated issue:
  • Changes UI
  • Requires DB Migration.
  • Confirm DB Migration upgrade and downgrade tested.
  • Introduces new feature or API
  • Removes existing feature or API

REVIEWERS

@mistercrunch @khtruong @etr2460

Copy link
Member

@mistercrunch mistercrunch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor comments, otherwise LGTM

@villebro
Copy link
Member

This is a nice feature. However, it seems to be unnecessarily specific to Presto, and should be fairly easy to enable for other engines, too, by moving as much of the logic as possible to BaseEngineSpec raising NotImplementedError() if not enabled (the Presto spec is getting fairly heavy lately, and there's probably other stuff that could be made more generic to benefit other engines). Probably ok to keep this in Presto for now, and I can probably work on making this accessible to other engines in a later PR.

@betodealmeida
Copy link
Member Author

This is a nice feature. However, it seems to be unnecessarily specific to Presto, and should be fairly easy to enable for other engines, too, by moving as much of the logic as possible to BaseEngineSpec raising NotImplementedError() if not enabled (the Presto spec is getting fairly heavy lately, and there's probably other stuff that could be made more generic to benefit other engines). Probably ok to keep this in Presto for now, and I can probably work on making this accessible to other engines in a later PR.

I agree. I think we need to start by adding an abstract method to BaseEngineSpec for running queries, and then it should be trivial to extend this to other engines. I'll create a ticket and give it a try when I have some bandwidth.

@betodealmeida
Copy link
Member Author

@mistercrunch is this good to go as soon as tests pass?

@villebro
Copy link
Member

LGTM. It hit me, that we should also offer a "get CREATE TABLE statement". I often like to add comments for both table and columns, and those would be convenient to see with the click of a button. So down the line perhaps get_create_view could be refactored to get_create_statement and would return the "CREATE TABLE" or "CREATE VIEW", depending on the type. But let's save that for a later PR.

@betodealmeida betodealmeida merged commit 8877794 into apache:master Sep 17, 2019
@codecov-io
Copy link

Codecov Report

Merging #8213 into master will decrease coverage by 0.06%.
The diff coverage is 42.85%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8213      +/-   ##
==========================================
- Coverage   65.79%   65.72%   -0.07%     
==========================================
  Files         480      481       +1     
  Lines       23273    23317      +44     
  Branches     2567     2572       +5     
==========================================
+ Hits        15312    15326      +14     
- Misses       7823     7853      +30     
  Partials      138      138
Impacted Files Coverage Δ
superset/views/core.py 70.41% <ø> (ø) ⬆️
superset/assets/src/components/TableSelector.jsx 77.69% <0%> (-6.48%) ⬇️
superset/db_engine_specs/base.py 85.61% <40%> (-0.49%) ⬇️
...rset/assets/src/SqlLab/components/TableElement.jsx 83.52% <50%> (-0.81%) ⬇️
superset/db_engine_specs/presto.py 72.37% <53.33%> (-1.48%) ⬇️
superset/assets/src/SqlLab/components/ShowSQL.jsx 55.55% <55.55%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4132d8f...d93c426. Read the comment docs.

@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 0.35.0 labels Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels size/L 🚢 0.35.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants