Самый простой способ переименовать модель с помощью Django / South?

Я искал ответ на этот вопрос на сайте Юга, в Google и SO, но не мог найти простого способа сделать это.

Я хочу переименовать модель Django с помощью South. Допустим, у вас есть следующее:

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

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

и вы хотите преобразовать Foo в Bar, а именно

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

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

Чтобы не усложнять, я просто пытаюсь изменить имя с Fooна Bar, но пока игнорирую fooчлена FooTwo.

Как проще всего это сделать, используя Юг?

1. Возможно, я мог бы выполнить миграцию данных, но это кажется довольно сложным.
2. Напишите, например db.rename_table('city_citystate', 'geo_citystate'), настраиваемую миграцию, но я не уверен, как исправить внешний ключ в этом случае.
3. Более простой способ, который вы знаете?

Чтобы ответить на ваш первый вопрос, простое переименование модели / таблицы довольно просто. Выполните команду:

./manage.py schemamigration yourapp rename_foo_to_bar --empty

(Обновление 2: попробуйте --autoвместо того, --emptyчтобы избежать предупреждения ниже. Спасибо @KFB за подсказку.)

Если вы используете старую версию south, вам понадобится startmigrationвместо schemamigration.

Затем вручную отредактируйте файл миграции, чтобы он выглядел так:

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

Вы можете сделать это проще, используя db_tableопцию Meta в вашем классе модели. Но каждый раз, когда вы это делаете, вы увеличиваете унаследованный вес своей кодовой базы - если имена классов отличаются от имен таблиц, ваш код сложнее понимать и поддерживать. Для ясности я полностью поддерживаю такие простые рефакторинги.

(обновление) Я только что попробовал это в производственной среде и получил странное предупреждение, когда пошел применять миграцию. Он сказал:

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

Я ответил «нет», и вроде бы все нормально.

Внесите изменения models.pyи запустите

./manage.py schemamigration --auto myapp

Когда вы проверите файл миграции, вы увидите, что он удаляет таблицу и создает новую.

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

Это не совсем то, что вам нужно. Вместо этого отредактируйте миграцию так, чтобы она выглядела так:

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

В случае отсутствия updateоператора db.send_create_signalвызов создаст новый ContentTypeс новым названием модели. Но лучше использовать updateтот, ContentTypeкоторый у вас уже есть, если на него указывают объекты базы данных (например, через a GenericForeignKey).

Кроме того, если вы переименовали некоторые столбцы, которые являются внешними ключами переименованной модели, не забудьте

db.rename_column(myapp_model, foo_id, bar_id)

Юг не может этого сделать сам - откуда он знает, что Barпредставляет то, что Fooраньше? Я бы написал для этого специальную миграцию. Вы можете изменить свой ForeignKeyкод, как вы это делали выше, а затем просто переименовать соответствующие поля и таблицы, что вы можете делать как хотите.

Наконец, действительно ли вам нужно это делать? Мне еще не нужно было переименовывать модели - названия моделей - это всего лишь деталь реализации, особенно с учетом наличия verbose_nameопции Meta.

Я следил за решением Леопда выше. Но это не повлияло на названия моделей. Я вручную изменил его в коде (также в связанных моделях, где это называется FK). И сделал еще одну миграцию на юг, но с параметром --fake. Это делает имена моделей и имена таблиц одинаковыми.

Только что осознал, что можно сначала начать с изменения названий моделей, а затем отредактировать файл миграции перед их применением. Намного чище.