Changes between Initial Version and Version 1 of Ticket #30108, comment 11


Ignore:
Timestamp:
Nov 3, 2022, 11:50:27 AM (2 years ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #30108, comment 11

    initial v1  
    66
    77This means that combining operations now forces the usage of the `COPY` algorithm for both the column addition and foreign key constraint creation which we're still trying to determine if it might play a role in making some of our schema changes more problematic since we upgraded to 3.2 LTS.
     8
     9In summary the statement issues on `ForeignKey` addition before this change on recent versions of MySQL were along the lines of
     10
     11{{{#!sql
     12-- < Django 3.0 with explicit ALGORITHM
     13ALTER TABLE foo ADD COLUMN bar_id integer, ALGORITHM=INSTANT;
     14ALTER TABLE foo ADD CONSTRAINT bar_id_fk FOREIGN KEY foo(bar_id) REFERENCES bar(id), ALGORITM=COPY;
     15
     16-- >= Django 3.0 with explicit ALGORITHM
     17ALTER TABLE foo ADD COLUMN bar_id integer, ADD CONSTRAINT bar_id_fk FOREIGN KEY foo(bar_id) REFERENCES bar(id), ALGORITM=COPY;
     18}}}
     19
     20On a side note we've noticed that having the MySQL backend wrap foreign key constraint creation with `SET foreign_key_check=0` and `SET foreign_key_check=1` will allow the usage of `ALGORITHM=INPLACE` which might be a desirable behaviour to add in core since the schema editor can guarantee that no constraint violations will happen in the current session while adding the constraint.
Back to Top