> MySQL lacks support for transactions around schema alteration
operations, meaning that if a migration fails to apply you will have to
manually unpick the changes in order to try again (it’s impossible to roll
back to an earlier point).
>
> In addition, MySQL will fully rewrite tables for almost every schema
operation and generally takes a time proportional to the number of rows in
the table to add or remove columns. On slower hardware this can be worse
than a minute per million rows - adding a few columns to a table with just
a few million rows could lock your site up for over ten minutes.
>
> Finally, MySQL has relatively small limits on name lengths for columns,
tables and indexes, as well as a limit on the combined size of all columns
an index covers. This means that indexes that are possible on other
backends will fail to be created under MySQL.
--
Ticket URL: <https://code.djangoproject.com/ticket/35015>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Old description:
> Now that Django dropped support for MySQL 5.7, I think the documentation
> is no longer valid.
>
> > MySQL lacks support for transactions around schema alteration
> operations, meaning that if a migration fails to apply you will have to
> manually unpick the changes in order to try again (it’s impossible to
> roll back to an earlier point).
> >
> > In addition, MySQL will fully rewrite tables for almost every schema
> operation and generally takes a time proportional to the number of rows
> in the table to add or remove columns. On slower hardware this can be
> worse than a minute per million rows - adding a few columns to a table
> with just a few million rows could lock your site up for over ten
> minutes.
> >
> > Finally, MySQL has relatively small limits on name lengths for columns,
> tables and indexes, as well as a limit on the combined size of all
> columns an index covers. This means that indexes that are possible on
> other backends will fail to be created under MySQL.
New description:
Now that Django dropped support for MySQL 5.7, I think the documentation
is no longer valid.
> MySQL lacks support for transactions around schema alteration
operations, meaning that if a migration fails to apply you will have to
manually unpick the changes in order to try again (it’s impossible to roll
back to an earlier point).
>
> In addition, MySQL will fully rewrite tables for almost every schema
operation and generally takes a time proportional to the number of rows in
the table to add or remove columns. On slower hardware this can be worse
than a minute per million rows - adding a few columns to a table with just
a few million rows could lock your site up for over ten minutes.
>
> Finally, MySQL has relatively small limits on name lengths for columns,
tables and indexes, as well as a limit on the combined size of all columns
an index covers. This means that indexes that are possible on other
backends will fail to be created under MySQL.
https://docs.djangoproject.com/en/5.0/topics/migrations/#mysql
--
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:1>
Comment (by Simon Charette):
> MySQL lacks support for transactions around schema alteration
operations, meaning that if a migration fails to apply you will have to
manually unpick the changes in order to try again (it’s impossible to roll
back to an earlier point).
This is still true.
> In addition, MySQL will fully rewrite tables for almost every schema
operation and generally takes a time proportional to the number of rows in
the table to add or remove columns. On slower hardware this can be worse
than a minute per million rows - adding a few columns to a table with just
a few million rows could lock your site up for over ten minutes.
That's no longer true for most operations and should be adjusted. I guess
[https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html
we could link to MySQL's Online DDL operations docs].
> Finally, MySQL has relatively small limits on name lengths for columns,
tables and indexes, as well as a limit on the combined size of all columns
an index covers. This means that indexes that are possible on other
backends will fail to be created under MySQL.
I'm pretty sure [https://dev.mysql.com/doc/refman/8.0/en/innodb-
limits.html this is still true to a certain extent].
-----
Which parts of the documentation you believe are not accurate? Would you
be interested in submitting a patch that addresses the inaccuracies?
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:2>
Comment (by Nicolas Lupien):
> Which parts of the documentation you believe are not accurate?
I'm not a MySQL expert, it's just that reading this section of the docs
seemed outdated. Like you pointed out, many DDL operations in MySQL 8
happens without locking.
> Would you be interested in submitting a patch that addresses the
inaccuracies?
Yes, I'll be happy to do the research and submit a patch!
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:3>
* keywords: => mysql
* status: new => closed
* resolution: => needsinfo
* type: Uncategorized => Cleanup/optimization
Comment:
Maybe a middle sentence:
> In addition, MySQL will fully rewrite tables for almost every schema
operation and generally takes a time proportional to the number of rows in
the table to add or remove columns. On slower hardware this can be worse
than a minute per million rows - adding a few columns to a table with just
a few million rows could lock your site up for over ten minutes.
is a bit inaccurate, but you haven't presented any references to prove it.
Also, generally this paragraph is still valid. Closing as "needsinfo" for
now. Feel-free to investigate and provide details what and where is wrong
in docs.
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:4>
* status: closed => new
* resolution: needsinfo =>
Comment:
This is my first contribution, let me know if I missed something.
https://github.com/django/django/pull/17582
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:5>
* owner: nobody => Nicolas Lupien
* status: new => assigned
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:6>
Comment (by Simon Charette):
Thank you for your patch Nicolas! I think the wording for the online DDL
operations section is great but that we should keep the section about
InnoDB limitations.
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:7>
* needs_better_patch: 0 => 1
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:8>
* needs_better_patch: 1 => 0
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:9>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"d4c583682e7afc2b4e953b8c85af17f1c1514ba9" d4c58368]:
{{{
#!CommitTicketReference repository=""
revision="d4c583682e7afc2b4e953b8c85af17f1c1514ba9"
Fixed #35015 -- Updated MySQL notes in migrations topic.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:10>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"bc60b1e2925a400aa8188e035782ec2945123e57" bc60b1e]:
{{{
#!CommitTicketReference repository=""
revision="bc60b1e2925a400aa8188e035782ec2945123e57"
[5.0.x] Fixed #35015 -- Updated MySQL notes in migrations topic.
Backport of d4c583682e7afc2b4e953b8c85af17f1c1514ba9 from main
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/35015#comment:11>