CentreForDigitalHumanities / CentreForDigitalHumanities/django-shared-core
Changed db_type on MariaDB when migrating Django 4.x to 5.x
- Dominant language
- JavaScript
- Stars
- 1
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
https://docs.djangoproject.com/en/6.0/releases/5.0/#migrating-existing-uuidfield-on-mariadb-10-7
The Shared Core uses `UUIDField` in `cdh.files.db.BaseFile` requiring the precarious workaround described above. We would like to solve this on our side, and not require intervention on the library users' side.
Proposed solutions:
* **Always use `char(32)` for UUIDField**: This would be my go-to option considering the imminent sunsetting of Django 4.2, however this creates the inverse problem for applications using Postgres, which were already using native UUID's in Django 4.2.
* **Always use `char(32)` on MariaDB/MySQL**: This would only leave MariaDB applications stranded that started using `cdh.files` after Django 5.x. I can't think of one off the top of my head, but still not ideal.
The actual ideal solution would be a custom UUIDField that is aware of its migrated state. If it already has a column with a type, it sticks with its guns. Otherwise, defer to `super()`.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.