feat: add and use UUIDMixin for most models #30398
Conversation
superset/models/core.py
Outdated
| @@ -102,7 +102,7 @@ class KeyValue(Model): # pylint: disable=too-few-public-methods | |||
| value = Column(utils.MediumText(), nullable=False) | |||
|
|
|||
|
|
|||
| class CssTemplate(Model, AuditMixinNullable): | |||
| class CssTemplate(Model, AuditMixinNullable, UUIDMixin): | |||
There was a problem hiding this comment.
This was already incorrect, but in general it's idiomatic to place the mixin before the main class to ensure correct MRO (otherwise functionality in the main class may overwrite functionality in the mixin):
| class CssTemplate(Model, AuditMixinNullable, UUIDMixin): | |
| class CssTemplate(AuditMixinNullable, UUIDMixin, Model): |
github-actions
bot
added
i18n
mistercrunch
force-pushed
the
uuid_mixin
branch
from
41b6fe1
to
841b67e
Compare
github-actions
bot
removed
i18n
mistercrunch
requested review from
michael-s-molina,
betodealmeida and
eschutho
as code owners
|
Setting this as ready for review as we may want to repeat this pattern, and having |
|
|
||
|
|
||
| def upgrade(): | ||
| op.add_column( |
There was a problem hiding this comment.
@mistercrunch could you make sure the migration checks if the column exists when upgrading and downgrading?
There was a problem hiding this comment.
I think it would be good to create a utility for adding/removing columns that always performs this check.
There was a problem hiding this comment.
Seem like a decent idea, though wondering how to best to this. Not sure if false-negative or swallowed errors on db migrations is a thing, personally I don't think I've ever seen it. I've seen migrations that fail half-way through and bad states, but always with a clear error message.
Taking a step back and thinking about improving migrations-related code / process. One thing I'd like seen is collapsing/cleaning database migrations.
$ find superset/migrations/versions/|wc -l
980
Currently we have 980 migrations, I could collapse since say 1.0.0 or 2.0.0 and end up with much less migrations. Not sure if worth our while.
Maybe a more important thing I could spend a cycle or two on would be to clean the mismatches. When running alembic, it becomes evident that there's a lot of differences between what's declared in models and what's in the physical database, resulting on a vanilla alembic run generating lots of output.
If I was to align 100% on alembic, we could have a CI script that prevents deriving away between what's declared and how it gets stamped in the database.
There was a problem hiding this comment.
Not sure if false-negative or swallowed errors on db migrations is a thing, personally I don't think I've ever seen it.
I think we should not swallow the errors. It's more about making sure that migrations are more resilient. Dropping a column that does not exist or adding a column that matches the one in the database (same config) should not throw errors. We could log warnings instead so that admins are aware.
There was a problem hiding this comment.
Maybe a more important thing I could spend a cycle or two on would be to clean the mismatches. When running alembic, it becomes evident that there's a lot of differences between what's declared in models and what's in the physical database, resulting on a vanilla alembic run generating lots of output.
If I was to align 100% on alembic, we could have a CI script that prevents deriving away between what's declared and how it gets stamped in the database.
That's a good idea 👍🏼
Proof of concept for adding uuid to most table. This is just a DRAFT for now but could be used to sprinkly uuids to all models
Needed to roll out: