Warum wird bei einigen Migrationen "sqlmigrate" leer oder dieselbe SQL in beide Richtungen angezeigt?

Question

Ich arbeite an der Aktualisierung eines Legacy-Projekts, derzeit noch unter Python 2.7.18 als höchstem Python-2 vor dem Upgrade auf 3. Nach dem Upgrade von Django von 1.8.13 auf 1.11.29 erfordert das Projekt einige Datenbankänderungen (nicht angewendete Migrationen). und ich verwende den Befehl python manage.py sqlmigrate, um die SQL-Anweisungen zu überprüfen.

Ich habe einige Fragen und alle Beiträge werden sehr geschätzt:

1. Einige Migrationen, z. B. 0002_logentry_remove_auto_addunten, SQL enthält nur Kommentare. Ich frage mich, warum.

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

1. Bei der Migration 0002_auto_20160226_1747ist SQL sowohl für Vorwärts- als auch für Rückwärtsrichtung (- Rückwärtsrichtung) gleich, und ich frage mich auch, 1) warum und 2) ob dies ein Problem sein sollte. Ich möchte nur vorsichtig mit der Produktionsdatenbank sein und danke Ihnen für Ihre Hinweise.

(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;

Diese Frage ist übrigens eine Fortsetzung einer vorherigen .

Answer 1

Django-Migrationen sind erforderlich, wenn sich das Modell ändert, aber nicht alle Modelländerungen erfordern SQL-Änderungen.

Die 0002_logentry_remove_auto_addMigration ändert die defaultund editable-Werte des action_timeFeldes. Es sind keine SQL-Schemaänderungen erforderlich. Der Code enthält einen Kommentar, der dies bestätigt.

Ich denke, dass die 0002_auto_20160226_1747Migration für diese Änderung ist . Es sieht so aus, als wären überhaupt keine SQL-Änderungen erforderlich, aber aus irgendeinem Grund entfernt Django dieselbe Einschränkung und fügt sie in beide Richtungen hinzu.

In großen Datenbanken kann das Hinzufügen von Einschränkungen zu Sperren führen. Daher sollten Sie diese Migration möglicherweise vortäuschen , anstatt sie auszuführen . Seien Sie jedoch vorsichtig, es ist leicht, es --fakefalsch zu verwenden und Ihre Migrationen und Datenbanken nicht mehr synchron zu halten. Im Idealfall testen Sie die Ausführung der Migrationen in einer Entwicklungsumgebung und entscheiden dann, ob die Ausführung nur in Ordnung ist migrateoder ob Sie einen komplizierteren Plan benötigen.