Adjust atomic DDL documentation to avoid ambiguity with MySQL 8+ notion of atomic DDL.

[Nathan Klug]

I noticed that Django's documentation says "The atomic attribute doesn’t have an effect on databases that don’t support DDL transactions (e.g. MySQL, Oracle)." here: ​https://docs.djangoproject.com/en/2.1/howto/writing-migrations/#non-atomic-migrations

I noticed that MySQL 8 adds support for atomic DDL statements though (​https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html). Is this something that Django supports when using MySQL 8 and the documentation is imprecise (if so, consider this a bug report to clarify documentation)? or is this not yet supported (if so, consider this a feature request)? Thanks!

​https://github.com/django/django/pull/10718

[Simon Charette]

The documentation is currently correct, the feature is disabled for all versions of MySQL. Did you give a try at running the suite locally against MySQL 8?

[Tim Graham]

I tried adding:

@cached_property
def can_rollback_ddl(self):
    return not self.connection.mysql_is_mariadb and self.connection.mysql_version >= (8, 0)

to django/db/backends/mysql/features.py and was met with some failures such as "SAVEPOINT s140283873580864_x2 does not exist') in cache.tests.CreateCacheTableForDBCacheTests.test_createcachetable_observes_database_router that I couldn't figure out at a quick glance.

[Tom Forbes]

I had a look at this failure and I think I know why it occurs: ​https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html

When using atomic DDL in mysql certain statements immediately and implicitly commit the transaction. Django doesn't know about this, so it ends up failing because the savepoints no longer exist.

In any case MySQL cannot roll back DDL like Postgres can, and Atomic DDL is actually not the same as transactional DDL. I'm not entirely sure but it seems (according to this ​https://mysqlserverteam.com/atomic-ddl-in-mysql-8-0/) that it's just implicitly enabled/working without any additional code changes.

If I'm correct it might be worth adding a note to the docs because of the name clash, we use 'atomic' to mean a transaction that can be rolled back, MySQL uses 'atomic ddl' to mean 'individual DDL statements are crash safe' (or something...)

[Simon Charette]

Thanks for the investigation Tom.

When using atomic DDL in mysql certain statements immediately and implicitly commit the transaction...

Yeah that's the exact opposite of what Django means by atomic DDL as what PostgreSQL and SQLite support.

I've repurposed the ticket to be a documentation adjustment instead.

[Tim Graham <timograham@…>]

In ad191d9:

Fixed #29895 -- Doc'd why MySQL's atomic DDL statements don't work for atomic migrations.

[Tim Graham <timograham@…>]

In 4c50673:

[2.1.x] Fixed #29895 -- Doc'd why MySQL's atomic DDL statements don't work for atomic migrations.

Backport of ad191d9e011f37d79a7f2df3da881b06539aaaea from master.