#33507: Use native UUID data type on MariaDB 10.7+
-------------------------------------+-------------------------------------
Reporter: Mariusz Felisiak | Owner: raydeal
Type: New feature | Status: closed
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: mariadb | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Christoph Bülter):
I would like to add some thoughts about my recent experience using MariaDB
10.11 and upgrading from Django 3 to 5:
- The recommended upgrade path for UUIDFields in the docs
(https://docs.djangoproject.com/en/5.2/releases/5.0/#migrating-existing-
uuidfield-on-mariadb-10-7) currently is defining a custom
`Char32UUIDField` class and using that instead of the builtin
`models.UUIDField`, to keep using a `CHAR(32)` column type under the hood.
- This however means developers will have to remember using that custom
field, so if someone forgets and accidentally creates a new
`models.UUIDField` later on, there will be a mix of `CHAR(32)` and `UUID`
columns in the database, which is probably not ideal. I would like to
reiterate on an alternative upgrade path:
- In previous comments, valid concerns have been raised about potential
issues with large tables, table rebuilds and UUIDFields used as primary-
keys or in foreign-key relations. Our migration scenario is much simpler,
though: We have lots of UUIDFields, but the tables are relatively small
and they are not used as primary-keys or in relations.
- Instead of using that aforementioned `Char32UUIDField`, it made more
sense for us to just convert all existing `models.UUIDField` from
`CHAR(32)` to `UUID` in a Django data migration, and then use the builtin
`models.UUIDField` moving forward, so everything is based on the `UUID`
type. The data migration could look like:
{{{#!python
class Migration(migrations.Migration):
dependencies = [
("my_app", "0001_initial"),
]
operations = [
# Update UUIDFields from CHAR(32) to UUID
migrations.RunSQL(
sql="""
ALTER TABLE myapp_table1 MODIFY field1 UUID NOT NULL;
ALTER TABLE myapp_table2 MODIFY field2 UUID NOT NULL;
ALTER TABLE myapp_table3 MODIFY field3 UUID NOT NULL;
""",
)
]
}}}
I believe for our scenario this is easier to maintain longterm, since
there's nothing special to remember about and no danger of introducing
mixed types.
Would this be worth mentioning in the docs as an alternative option (aka
the first link I posted)?
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:24>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019a7c77ca33-8d9b420f-cf78-4d8f-a25a-2d494e12fd86-000000%40eu-central-1.amazonses.com.
