Der einfachste Weg, ein Modell mit Django / South umzubenennen?

Ich habe auf der Website von South, Google und SO nach einer Antwort darauf gesucht, konnte aber keinen einfachen Weg finden, dies zu tun.

Ich möchte ein Django-Modell mit South umbenennen. Angenommen, Sie haben Folgendes:

class Foo(models.Model):
    name = models.CharField()

class FooTwo(models.Model):
    name = models.CharField()
    foo = models.ForeignKey(Foo)

und Sie möchten nämlich Foo in Bar konvertieren

class Bar(models.Model):
    name = models.CharField()

class FooTwo(models.Model):
    name = models.CharField()
    foo = models.ForeignKey(Bar)

Um es einfach zu halten, versuche ich nur, den Namen von Fooin zu ändern Bar, aber ignoriere das fooMitglied FooTwovorerst.

Was ist der einfachste Weg, dies mit South zu tun?

1. Ich könnte wahrscheinlich eine Datenmigration durchführen, aber das scheint ziemlich kompliziert zu sein.
2. Schreiben Sie beispielsweise eine benutzerdefinierte Migration, db.rename_table('city_citystate', 'geo_citystate')aber ich bin nicht sicher, wie der Fremdschlüssel in diesem Fall behoben werden soll.
3. Ein einfacher Weg, den Sie kennen?

Um Ihre erste Frage zu beantworten, ist das einfache Umbenennen von Modell / Tabelle ziemlich einfach. Führen Sie den folgenden Befehl aus:

./manage.py schemamigration yourapp rename_foo_to_bar --empty

(Update 2: Versuchen Sie --autostattdessen --empty, die folgende Warnung zu vermeiden. Vielen Dank an @KFB für den Tipp.)

Wenn Sie eine ältere Version von South verwenden, benötigen Sie startmigrationstattdessen schemamigration.

Bearbeiten Sie dann die Migrationsdatei manuell wie folgt:

class Migration(SchemaMigration):

    def forwards(self, orm):
        db.rename_table('yourapp_foo', 'yourapp_bar')


    def backwards(self, orm):
        db.rename_table('yourapp_bar','yourapp_foo')   

Sie können dies einfacher mit der db_tableOption Meta in Ihrer Modellklasse erreichen. Aber jedes Mal, wenn Sie dies tun, erhöhen Sie das Legacy-Gewicht Ihrer Codebasis. Wenn sich Klassennamen von Tabellennamen unterscheiden, ist Ihr Code schwieriger zu verstehen und zu pflegen. Der Klarheit halber unterstütze ich die Durchführung einfacher Refactorings wie diese voll und ganz.

(Update) Ich habe dies gerade in der Produktion versucht und eine seltsame Warnung erhalten, als ich die Migration anwendete. Es sagte:

The following content types are stale and need to be deleted:

    yourapp | foo

Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.

Ich antwortete "nein" und alles schien in Ordnung zu sein.

Nehmen Sie die Änderungen vor models.pyund führen Sie sie aus

./manage.py schemamigration --auto myapp

Wenn Sie die Migrationsdatei untersuchen, werden Sie feststellen, dass eine Tabelle gelöscht und eine neue erstellt wird

class Migration(SchemaMigration):

    def forwards(self, orm):
        # Deleting model 'Foo'                                                                                                                      
        db.delete_table('myapp_foo')

        # Adding model 'Bar'                                                                                                                        
        db.create_table('myapp_bar', (
        ...
        ))
        db.send_create_signal('myapp', ['Bar'])

    def backwards(self, orm):
        ...

Das ist nicht ganz das, was Sie wollen. Bearbeiten Sie stattdessen die Migration so, dass sie wie folgt aussieht:

class Migration(SchemaMigration):

    def forwards(self, orm):
        # Renaming model from 'Foo' to 'Bar'                                                                                                                      
        db.rename_table('myapp_foo', 'myapp_bar')                                                                                                                        
        if not db.dry_run:
            orm['contenttypes.contenttype'].objects.filter(
                app_label='myapp', model='foo').update(model='bar')

    def backwards(self, orm):
        # Renaming model from 'Bar' to 'Foo'                                                                                                                      
        db.rename_table('myapp_bar', 'myapp_foo')                                                                                                                        
        if not db.dry_run:
            orm['contenttypes.contenttype'].objects.filter(app_label='myapp', model='bar').update(model='foo')

Wenn die updateAnweisung nicht vorhanden ist, wird beim db.send_create_signalAufruf ein neuer ContentTypemit dem neuen Modellnamen erstellt. Es ist jedoch besser, nur updatedas zu haben, was ContentTypeSie bereits haben, falls Datenbankobjekte darauf verweisen (z. B. über a GenericForeignKey).

Wenn Sie einige Spalten umbenannt haben, die Fremdschlüssel für das umbenannte Modell sind, vergessen Sie dies nicht

db.rename_column(myapp_model, foo_id, bar_id)

Der Süden kann es nicht selbst tun - woher weiß er, dass dies das Bardarstellt, was Foofrüher war? Für diese Art von Dingen würde ich eine benutzerdefinierte Migration schreiben. Sie können Ihren ForeignKeyIn-Code wie oben beschrieben ändern. Anschließend müssen Sie nur die entsprechenden Felder und Tabellen umbenennen, was Sie nach Belieben tun können.

Müssen Sie das wirklich tun? Ich muss Modelle noch umbenennen - Modellnamen sind nur ein Implementierungsdetail - insbesondere angesichts der Verfügbarkeit der verbose_nameMeta-Option.

Ich folgte der obigen Lösung von Leopd. Dies änderte jedoch nichts an den Modellnamen. Ich habe es manuell im Code geändert (auch in verwandten Modellen, in denen dies als FK bezeichnet wird). Und eine weitere Südwanderung gemacht, aber mit --fake Option. Dadurch werden Modell- und Tabellennamen identisch.

Gerade realisiert, könnte man zuerst mit dem Ändern der Modellnamen beginnen und dann die Migrationsdatei bearbeiten, bevor man sie anwendet. Viel sauberer.