2016-12-12 4 views
2

Ich benutze Django 1.9.2 mit Python 3.4.2.Django - Änderung des Validierungsnamens verursacht Rückverfolgung bei der Migration

In der ersten Hälfte des Entwicklungszyklus hatte ich diesen Code:

class ModificationOrder(ERN): 
... 
    san_amount = models.IntegerField(default=0, \ 
    validators=[validate_modificationorder_san_amount]) 

, und ich erstellt eine anfängliche Migration, die diese Zeile in der 0001_initial.py Datei geführt:

migrations.CreateModel(
    ... 
    fields = [ 
     ... 
     ('san_amount', models.IntegerField(default=0, validators=[shop.validators.validate_modificationorder_san_amount])), 
    ]) 

. Später hatte ich ein paar Migrationen und ich löschte das San_amount Feld aus dem Modell, aber wahrscheinlich ist das nicht auf mein Problem bezogen. Jetzt

Ich habe versucht, den Namen des Prüfers zu validate_resource_san_amount ändern, aber nach dem Ändern es Runserver Ergebnisse diesen Fehler:

python manage.py runserver 
Performing system checks... 

System check identified no issues (0 silenced). 
Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x7f8ec1a5a510> 
Traceback (most recent call last): 
    File "/home/csa.virtualenvs/sccdb34/lib/python3.4/site-packages/django/utils/autoreload.py", line 226, in wrapper 
fn(*args, **kwargs) 
    File "/home/csa/.virtualenvs/sccdb34/lib/python3.4/site-packages/django/core/management/commands/runserver.py", line 117, in inner_run 
self.check_migrations() 
    File "/home/csa/.virtualenvs/sccdb34/lib/python3.4/site-packages/django/core/management/commands/runserver.py", line 163, in check_migrations 
executor = MigrationExecutor(connections[DEFAULT_DB_ALIAS]) 
    File "/home/csa/.virtualenvs/sccdb34/lib/python3.4/site-packages/django/db/migrations/executor.py", line 20, in __init__ 
self.loader = MigrationLoader(self.connection) 
    File "/home/csa/.virtualenvs/sccdb34/lib/python3.4/site-packages/django/db/migrations/loader.py", line 49, in __init__ 
self.build_graph() 
    File "/home/csa/.virtualenvs/sccdb34/lib/python3.4/site-packages/django/db/migrations/loader.py", line 170, in build_graph 
self.load_disk() 
    File "/home/csa/.virtualenvs/sccdb34/lib/python3.4/site-packages/django/db/migrations/loader.py", line 105, in load_disk 
migration_module = import_module("%s.%s" % (module_name, migration_name)) 
    File "/home/csa/.virtualenvs/sccdb34/lib/python3.4/importlib/__init__.py", line 109, in import_module 
return _bootstrap._gcd_import(name[level:], package, level) 
    File "<frozen importlib._bootstrap>", line 2254, in _gcd_import 
    File "<frozen importlib._bootstrap>", line 2237, in _find_and_load 
    File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked 
    File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked 
    File "<frozen importlib._bootstrap>", line 1129, in _exec 
    File "<frozen importlib._bootstrap>", line 1471, in exec_module 
    File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed 
    File "/home/csa/git/sccdb/sccdb/shop/migrations/0001_initial.py", line 12, in <module> 
class Migration(migrations.Migration): 
    File "/home/csa/git/sccdb/sccdb/shop/migrations/0001_initial.py", line 226, in Migration 
('san_amount', models.IntegerField(default=0, validators=[shop.validators.validate_modificationorder_san_amount])), 
AttributeError: 'module' object has no attribute 'validate_modificationorder_san_amount' 

.

Um das Problem zu lösen, denke ich, es wäre genug, um alle validate_modificationorder_san_amount auf validate_resource_san_amount zu ändern, aber ich denke konzeptionell ist es eine schlechte Idee. Wie soll ich mit diesem Problem richtig umgehen? - Um einen Validierungsnamen zu ändern, der sich bereits in einer Migrationsdatei befindet.

+0

ja, mach es. In diesem Fall würde ich die Migrationsdatei auch manuell bearbeiten. –

Antwort

0

Schritt eins, gehen Sie dafür, benennen Sie die Verwendung in der Migrationsdatei, da ich bezweifle, dass es irgendwelche negativen Auswirkungen von dem haben wird, was Sie hier gesagt haben.

Aber mehr als das würde es helfen, squashmigrations. Teil der Schritte wie in den Dokumenten beschrieben.

Deleting all the migration files it replaces.

Updating all migrations that depend on the deleted migrations to depend on the squashed migration instead.

Removing the replaces attribute in the Migration class of the squashed migration (this is how Django tells that it is a squashed migration).

+0

Aber mehr als das, es wird helfen, runserver! ;-) Ich denke der Teil mit Squashmigrationen ist nicht mit der Frage verbunden. –

+0

@AlexanderTyapkov - Dies hat nichts mit Runserver zu tun, außer dass der Op den Fehler sieht. Das ganze Problem ist, dass eine Migrationsdatei Verweise auf Code enthält, die nicht länger gelten. Daher quetschen Migrationen. – Sayse

+0

war es ein Witz. Mit runserver meine ich, dass er nach der Korrektur der Migrationsdatei nicht nur Squashmigrationen durchführen, sondern hoffentlich auch den Server betreiben kann. Die einzige Sache ist, dass Autor nicht über das Zerquetschen von Migrationen fragte. Er hat nur ein kleines Problem in der Migrationsdatei. –

1

Wenn Sie nicht die Migration noch oder laufen in dieses Problem zerquetschen weg, wenn die Tests laufen (wie ich), können Sie dieses Problem umgehen, indem Sie die alten Namen dort zu verlassen und die neue Funktion von ihm fordern.

# Legacy name needed by migration 0001_initial.py 
def validate_modificationorder_san_amount(value):  
    return validate_resource_san_amount(value) 
Verwandte Themen