Najłatwiejszy sposób na zmianę nazwy modelu przy użyciu Django / South?

Szukałem odpowiedzi na to pytanie w witrynie South, Google i SO, ale nie mogłem znaleźć prostego sposobu, aby to zrobić.

Chcę zmienić nazwę modelu Django przy użyciu South. Załóżmy, że masz:

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

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

i chcesz przekonwertować Foo na Bar, a mianowicie

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

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

Aby to uprościć, po prostu próbuję zmienić nazwę z Foona Bar, ale na razie zignoruję fooczłonka FooTwo.

Jaki jest najłatwiejszy sposób na zrobienie tego za pomocą South?

1. Prawdopodobnie mógłbym przeprowadzić migrację danych, ale wydaje się to dość skomplikowane.
2. Napisz niestandardową migrację, np. db.rename_table('city_citystate', 'geo_citystate')Ale nie jestem pewien, jak naprawić klucz obcy w tym przypadku.
3. Łatwiejszy sposób, który znasz?

Odpowiadając na pierwsze pytanie, prosta zmiana nazwy modelu / tabeli jest dość prosta. Uruchom polecenie:

./manage.py schemamigration yourapp rename_foo_to_bar --empty

(Aktualizacja 2: spróbuj --autozamiast --emptyuniknąć poniższego ostrzeżenia. Dzięki @KFB za wskazówkę).

Jeśli używasz starszej wersji South, będziesz potrzebować startmigrationzamiast schemamigration.

Następnie ręcznie edytuj plik migracji, aby wyglądał następująco:

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')   

Możesz to zrobić w prostszy sposób, używając db_tableopcji Meta w swojej klasie modelu. Ale za każdym razem, gdy to robisz, zwiększasz wagę swojej bazy kodu - posiadanie nazw klas różniących się od nazw tabel sprawia, że ​​kod jest trudniejszy do zrozumienia i utrzymania. W pełni popieram robienie prostych refaktoryzacji, takich jak ta ze względu na przejrzystość.

(aktualizacja) Właśnie wypróbowałem to w środowisku produkcyjnym i otrzymałem dziwne ostrzeżenie, gdy poszedłem zastosować migrację. Powiedziało:

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'.

Odpowiedziałem „nie” i wszystko wydawało się być w porządku.

Wprowadź zmiany, models.pya następnie uruchom

./manage.py schemamigration --auto myapp

Po sprawdzeniu pliku migracji zobaczysz, że usuwa on tabelę i tworzy nową

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):
        ...

Nie do końca tego chcesz. Zamiast tego edytuj migrację tak, aby wyglądała następująco:

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')

W przypadku braku updateoświadczenia db.send_create_signalwywołanie utworzy nowy ContentTypez nową nazwą modelu. Ale lepiej jest po prostu updateto, ContentTypeco już masz, na wypadek, gdyby wskazały na niego obiekty bazy danych (np. Poprzez a GenericForeignKey).

Ponadto, jeśli zmieniono nazwy niektórych kolumn, które są kluczami obcymi, na model o zmienionej nazwie, nie zapomnij o tym

db.rename_column(myapp_model, foo_id, bar_id)

Południe nie może tego zrobić samo - skąd wie, że Barreprezentuje to, co Fookiedyś? To jest rodzaj rzeczy, dla której napisałbym niestandardową migrację. Możesz zmienić swój ForeignKeykod tak, jak zrobiłeś to powyżej, a wtedy wystarczy zmienić nazwy odpowiednich pól i tabel, co możesz zrobić w dowolny sposób.

Wreszcie, czy naprawdę musisz to zrobić? Nie muszę jeszcze zmieniać nazw modeli - nazwy modeli to tylko szczegół implementacji - szczególnie biorąc pod uwagę dostępność verbose_nameopcji Meta.

Postępowałem zgodnie z powyższym rozwiązaniem Leopda. Ale to nie zmieniło nazw modeli. Zmieniłem to ręcznie w kodzie (również w powiązanych modelach, gdzie jest to określane jako FK). I przeprowadziłem kolejną migrację na południe, ale z opcją --fake. Dzięki temu nazwy modeli i nazwy tabel są takie same.

Właśnie sobie uświadomiłem, że można najpierw zacząć od zmiany nazw modeli, a następnie edytować plik migracji przed ich zastosowaniem. Dużo czystsze.