Fixação tabela de auth_permission depois de renomear um modelo no Django

votos
6

De vez em quando, você tem a necessidade de mudar o nome de um modelo no Django (ou, em um caso recente que eu encontrei, dividir um modelo em duas, com nomes novos / diferentes). Sim, um bom planejamento ajuda a evitar esta situação, mas às vezes a realidade intervém.

Depois de renomear tabelas correspondentes no db e fixação de código afetado, um problema permanece: As permissões concedidas a usuários ou grupos para operar nesses modelos ainda referencia os nomes antigos modelo. Existe alguma maneira automatizada ou semi-automatizada para corrigir isso, ou é apenas uma questão de cirurgia db manual? (Em desenvolvimento você pode soltar a tabela auth_permissions e syncdb para recriá-lo, mas a produção não é tão simples).

Publicado 27/02/2009 em 08:12
fonte usuário
Em outras línguas...                            


4 respostas

votos
2

Se você passou a ter usado uma migração do esquema do Sul para renomear a tabela, a seguinte linha na migração para a frente teria feito isso automaticamente:

db.send_create_signal('appname', ['modelname'])
Respondeu 11/09/2012 em 01:06
fonte usuário

votos
2

Aqui está um trecho que preenche contenttypes e permissões ausentes. Pergunto-me se poderia ser estendido para pelo menos fazer algum do trabalho de burro para limpar auth_permissions.

Respondeu 27/02/2009 em 16:15
fonte usuário

votos
1

Recentemente, tive este problema e escreveu uma função para resolvê-lo. Você tipicamente terá uma discrepância com ambas as tabelas ContentType e permissão se você renomear um modelo / table. Django foi construído com funções auxiliares para resolver o problema e você pode usá-los como segue:

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()
Respondeu 11/12/2014 em 22:16
fonte usuário

votos
0

Eu tenho a meio caminho através de uma longa resposta que detalhou o plano de ataque eu tomaria nesta situação, mas como eu estava escrevendo eu percebi que provavelmente não há nenhuma maneira em torno de ter que fazer uma parada para manutenção nesta situação.

Você pode minimizar o tempo de inatividade por ter um script loaddata preparado é claro, embora o cuidado deve ser tomado para garantir que os auth_perms chaves primárias estão em sincronia.

ver também resposta curta: nenhuma maneira automatizada de fazer isso do que eu estou ciente.

Respondeu 27/02/2009 em 09:13
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more