For some migrations, why `sqlmigrate` shows empty, or the same SQL both directions?

问题

I'm working on upgrading a legacy project, currently still on Python 2.7.18 as the highest Python-2 before upgrade to 3. After upgrading Django from 1.8.13 to 1.11.29, the project requires some database changes (unapplied migrations), and I'm using command python manage.py sqlmigrate to review the SQL statements.

I have some questions, and any inputs will be highly appreciated:

Some migrations, e.g. 0002_logentry_remove_auto_add below, SQL only contains comment, I'm wondering why.

(venv) [user@server app]$ python manage.py sqlmigrate             admin      0002_logentry_remove_auto_add
BEGIN;
--
-- Alter field action_time on logentry
--
COMMIT;

For migration 0002_auto_20160226_1747, SQL is the same for both forward and backward (--backwards) directions, and I'm also wondering 1) why, and 2) whether this should be a concern. Just want to be cautious with the production database, and thank you for your pointers.

(venv) [user@server app]$ python manage.py sqlmigrate             authtoken  0002_auto_20160226_1747
BEGIN;
--
-- Change Meta options on token
--
--
-- Alter field created on token
--
--
-- Alter field key on token
--
--
-- Alter field user on token
--
ALTER TABLE `authtoken_token` DROP FOREIGN KEY `authtoken_token_user_id_535fb363_fk_auth_user_id`;
ALTER TABLE `authtoken_token` ADD CONSTRAINT `authtoken_token_user_id_35299eff_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`);
COMMIT;

(venv) [user@server app]$ python manage.py sqlmigrate --backwards authtoken  0002_auto_20160226_1747
BEGIN;
--
-- Alter field user on token
--
ALTER TABLE `authtoken_token` DROP FOREIGN KEY `authtoken_token_user_id_535fb363_fk_auth_user_id`;
ALTER TABLE `authtoken_token` ADD CONSTRAINT `authtoken_token_user_id_35299eff_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`);
--
-- Alter field key on token
--
--
-- Alter field created on token
--
--
-- Change Meta options on token
--
COMMIT;

By the way, this question is a follow up to a previous one.

回答1:

Django migrations are required when the model changes, but not all model changes require SQL changes.

The 0002_logentry_remove_auto_add migration changes the default and editable values of the action_time field. No SQL schema changes are required. There's a comment in the code to confirm this.

I think that the 0002_auto_20160226_1747 migration is for this change. It looks like no SQL changes are required at all, but for some reason Django is removing and adding the same constraint in both directions.

On large databases, adding constraints could cause locks, so you might consider faking that migration instead of running it. Be careful though, it's easy to use --fake incorrectly and get your migrations and database out of sync. Ideally, you would test running the migrations in a dev environment, then decide whether it's ok to just run migrate or if you need a more complicated plan.

来源：https://stackoverflow.com/questions/64659454/for-some-migrations-why-sqlmigrate-shows-empty-or-the-same-sql-both-directio

标签

python

mysql

django

migration