Исправление таблицы auth_permission после переименования модели в Django

Question

Время от времени вам нужно переименовывать модель в Django (или, в одном недавнем случае, с которым я столкнулся, разбить одну модель на две с новыми / разными именами). Да, правильное планирование помогает избежать этой ситуации, но иногда вмешивается реальность.

После переименования соответствующих таблиц в БД и исправления уязвимого кода остается одна проблема: любые разрешения, предоставленные пользователям или группам для работы с этими моделями, по-прежнему ссылаются на старые имена моделей. Есть ли какой-нибудь автоматизированный или полуавтоматический способ исправить это, или это просто вопрос ручного хирургического вмешательства? (В процессе разработки вы можете удалить таблицу auth_permissions и syncdb, чтобы воссоздать ее, но производство не так просто).

Answer 1

Вот фрагмент , который заполняет пропущенные типы содержимого и разрешения. Интересно, можно ли его расширить, по крайней мере, для выполнения некоторой ослиной работы по очистке auth_permissions.

Answer 2

Если бы вы использовали миграцию схемы South для переименования таблицы, следующая строка в прямой миграции сделала бы это автоматически:

db.send_create_signal('appname', ['modelname'])

Answer 3

У меня недавно была эта проблема, и я написал функцию для ее решения. Обычно вы будете иметь расхождения с таблицами ContentType и Permission, если переименуете модель / таблицу. Django имеет встроенные вспомогательные функции для решения проблемы, и вы можете использовать их следующим образом:

from django.contrib.auth.management import create_permissions
from django.contrib.contenttypes.management import update_all_contenttypes
from django.db.models import get_apps

def update_all_content_types_and_permissions():
    for app in get_apps():
        create_permissions(app, None, 2)
    update_all_contenttypes()

Answer 4

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

Конечно, вы можете минимизировать время простоя, если подготовите скрипт loaddata, хотя необходимо убедиться, что первичные ключи auth_perms синхронизированы.

Также см. Краткий ответ: нет автоматизированного способа сделать это, о котором я знаю.