Backend only tagging system #6823
Conversation
betodealmeida
added
enhancement:request
xtinec
left a comment
xtinec
left a comment
There was a problem hiding this comment.
LGTM. I'll cherry-pick this into v0.31 to resolve the everlasting migration problems at Lyft. :)
Codecov Report
@@ Coverage Diff @@
## master #6823 +/- ##
==========================================
+ Coverage 56.16% 56.26% +0.09%
==========================================
Files 527 529 +2
Lines 23376 23593 +217
Branches 2794 2794
==========================================
+ Hits 13130 13274 +144
- Misses 9836 9909 +73
Partials 410 410
Continue to review full report at Codecov.
|
|
@williaster just want to double check with you, since you requested in the other PR to not have any frontend files. |
|
Merging as all the comments on the backend changes from the original PR, #5524, have been addressed in this revision. |
This PR introduces the backend changes for a tagging system for Superset, allowing dashboards, charts and queries to be tagged. It also allows searching for a given tag, and will be the basis for a new landing page (see #5327). # Implicit tags Dashboard, chart and (saved) queries have implicit tags related to their owners, types and favorites. For example, all objects owned by the admin have the tag `owner:1`. All charts have the tag `type:chart`. Objects favorited by the admin have the tag `favorited_by:1`. These tags are automatically added by a migration script, and kept in sync through SQLAlchemy event listeners. They are currently not surfaced to the user, but can be searched for. For example, it's possible to search for `owner:1` in the welcome page to see all objects owned by the admin, or even search for `owner:{{ current_user_id() }}`. (cherry picked from commit 8041b63)
|
We've been having trouble with this db migration in our sandbox environment. The initial deploy fails (likely due to the db migration timing out), somehow the tag and tagged_objects tables get created but not populated with any data and the alembic_version doesn't upgrade to the latest because of the timeout. So if we try to deploy again it fails because it tries to rerun this migration but the Tag table already exists. I was assuming that the tables should get added along with the data all on commit at the end, is that not true? Is there a way to optimize this migration? It takes a long time with all of the data we have. cc: @john-bodley @graceguo-supercat |
|
DDL operations like table creation cannot be part of transactions. |
|
@mistercrunch By "DDL operations like table creation cannot be part of transactions" you mean that the table creation should be in a separate migration than transactions like adding or changing data in tables? Does that mean someone needs to move everything added to Tag and TaggedObject out of this migration? |
mistercrunch
added
🏷️ bot
5 participants
This is the backend only part of #5524.