Changes between Version 2 and Version 3 of Ticket #33507, comment 24
- Timestamp:
- Nov 13, 2025, 3:47:21 AM (3 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33507, comment 24
v2 v3 5 5 - 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: 6 6 7 - 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.7 - 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 or constraints. 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/relations/constraints. 8 8 9 9 - 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: