--
Ticket URL: <https://code.djangoproject.com/ticket/33507>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Old description:
> MariaDB 10.7 introduces `UUID` data type, see [https://mariadb.com/kb/en
> /uuid-data-type/ docs] and [https://mariadb.org/10-7-preview-feature-
> uuid-data-type/ blog post]. We should corrected the
> `has_native_uuid_field` feature flag and use it instead of `char(32)`.
New description:
MariaDB 10.7 introduces `UUID` data type, see [https://mariadb.com/kb/en
/uuid-data-type/ docs] and [https://mariadb.org/10-7-preview-feature-uuid-
data-type/ blog post]. We should corrected the `has_native_uuid_field`
feature flag and use `uuid` instead of `char(32)`.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:1>
* stage: Unreviewed => Accepted
Old description:
> MariaDB 10.7 introduces `UUID` data type, see [https://mariadb.com/kb/en
> /uuid-data-type/ docs] and [https://mariadb.org/10-7-preview-feature-
> uuid-data-type/ blog post]. We should corrected the
> `has_native_uuid_field` feature flag and use `uuid` instead of
> `char(32)`.
New description:
MariaDB 10.7 introduces `UUID` data type, see [https://mariadb.com/kb/en
/uuid-data-type/ docs] and [https://mariadb.org/10-7-preview-feature-uuid-
data-type/ blog post]. We should correct the `has_native_uuid_field`
feature flag and use `uuid` instead of `char(32)`.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:2>
Comment (by Simon Charette):
Small note that we should make sure that changing this flag won't break
installs with `UUIDField` backend by `char(32)` columns as it might be
impractical for large installs to rebuild their whole table primary keys
otherwise.
If we don't document a clear upgrade path I foresee a few reports when
users attempt to add a `ForeignKey` referencing a model with a `UUIDField`
primary key that is backend by a `char(32)` and hit a MariaDB error
telling them that a foreign constraint cannot be created from a `uuid` to
a `char(32)` column.
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:3>
Comment (by Mariusz Felisiak):
Replying to [comment:3 Simon Charette]:
> Small note that we should make sure that changing this flag won't break
installs with `UUIDField` backend by `char(32)` columns as it might be
impractical for large installs to rebuild their whole table primary keys
otherwise.
>
> If we don't document a clear upgrade path I foresee a few reports when
users attempt to add a `ForeignKey` referencing a model with a `UUIDField`
primary key that is backed by a `char(32)` and hit a MariaDB error telling
them that a foreign constraint cannot be created from a `uuid` to a
`char(32)` column.
According to the [https://mariadb.org/10-7-preview-feature-uuid-data-type/
blog post], it should be possible to change a data type without manual
data conversion:
> ''With these basic conversion rules, you can migrate from your existing
CHAR/VARCHAR/TEXT hexadecimal text or BINARY/VARBINARY/BLOB encoded to
UUID using:''
> {{{
> CREATE TABLE t1 (id BINARY(16));
> ALTER TABLE t1 MODIFY COLUMN id UUID;
> }}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:4>
Comment (by Adam Johnson):
That `ALTER TABLE` still requires a table rebuild, which is impractical or
impossible for large installations’ PK's. But maybe the "upgrade path"
there would be "create a field subclass always backed by `char(32)`".
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:5>
Comment (by Simon Charette):
> With these basic conversion rules, you can migrate from your existing
CHAR/VARCHAR/TEXT hexadecimal text or BINARY/VARBINARY/BLOB encoded to
UUID using:
Unfortunately, this statement doesn't account for the fact that UUIDs are
often used as primary keys and thus referenced by other tables where this
approach simply won't work as you get in a chicken-egg problem with
foreign references. To perform this properly a manual dropping of
references, followed by type alterations of all tables involved, and final
step to recreate constraints is required which possibly will require table
rebuilds as Adam pointed out.
> But maybe the "upgrade path" there would be "create a field subclass
always backed by char(32)".
That seems like the most suitable upgrade path. It will likely require
documenting that all the generated migration operations should be wrapped
in `SeparateDatabaseAndState` unless we adapt the schema editor to avoid
`ALTER` when the generated SQL column of `from_field` and `to_field`
remains the same.
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:6>
Comment (by Adam Johnson):
> unless we adapt the schema editor to avoid `ALTER` when the generated
SQL column of `from_field` and `to_field` remains the same.
This sounds like generally a good idea any way!
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:7>
Comment (by Mariusz Felisiak):
Agreed, this can be tricky. I'd really like to come up with a doable
pattern that could be used in the future, because other emulated fields
may be implemented in the databases.
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:8>
* owner: nobody => Mohammad Ali Mehdizadeh
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:9>
* owner: Mohammad Ali Mehdizadeh => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:10>
* owner: nobody => raydeal
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:9>
Comment (by raydeal):
MariaDB 10.7 seems to be a short-term maintenance release
https://mariadb.org/about/#maintenance-policy, and django 4.1 still
supports version 10.3
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:10>
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:11>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:12>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:13>
Comment (by Mariusz Felisiak):
Replying to [comment:7 Adam Johnson]:
> > unless we adapt the schema editor to avoid `ALTER` when the generated
SQL column of `from_field` and `to_field` remains the same.
>
> This sounds like generally a good idea any way!
Looks like it already
[https://github.com/django/django/blob/05d70fb92b72f9701bea99c809a5edd53b290de9/django/db/backends/base/schema.py#L961-L966
works]. For example, I've changed `models.CharField(max_length=50,
unique=True)` to `models.SlugField(unique=True)` on PostgreSQL and Django
didn't alter the db type:
{{{#!sql
--
-- Alter field field_2 on mytestmodel
--
-- (no-op)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:14>
* needs_better_patch: 0 => 1
* needs_docs: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:15>
* needs_better_patch: 1 => 0
* needs_docs: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:16>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:17>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:18>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:19>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"7cd187a5ba58d7769039f487faeb9a5a2ff05540" 7cd187a]:
{{{
#!CommitTicketReference repository=""
revision="7cd187a5ba58d7769039f487faeb9a5a2ff05540"
Fixed #33507 -- Used UUID data type on MariaDB 10.7+.
Co-Authored-By: Mariusz Felisiak <felisiak...@gmail.com>
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:20>
Comment (by GitHub <noreply@…>):
In [changeset:"9c37103a98d030be110eb9ba8b7ed32a47240b28" 9c37103]:
{{{
#!CommitTicketReference repository=""
revision="9c37103a98d030be110eb9ba8b7ed32a47240b28"
Refs #33507 -- Doc'd using UUID data type on MariaDB 10.7+ in UUIDField
docs.
Follow up to 7cd187a5ba58d7769039f487faeb9a5a2ff05540.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33507#comment:21>