python - ¿Por qué Django realiza migraciones para los cambios help_text y verbose_name?

database-migration django-1.7

Question

Cuando cambio help_text o verbose_name para cualquiera de los campos de mi modelo y ejecuto las python manage.py makemigrations , detecta estos cambios y crea una nueva migración, por ejemplo, 0002_xxxx.py .

Estoy usando PostgreSQL y creo que estos cambios son irrelevantes para mi base de datos (me pregunto si existe un DBMS para el cual estos cambios sean relevantes).

¿Por qué Django genera migraciones para tales cambios? ¿Hay una opción para ignorarlos?

¿Puedo aplicar los cambios de 0002_xxxx.py a la migración anterior ( 0001_initial.py ) de forma manual y segura para eliminar 0002_xxxx.py ?

¿Hay alguna manera de actualizar la migración previa automáticamente?

Answer 1

Como @ChillarAnand señaló, hay un ticket para resolver este problema, pero hasta ahora (django 1.9.1) los comandos de migración no se han corregido.

La forma menos intrusiva de solucionarlo es crear su propio comando maketranslatedmigrations en <your-project>/management/commands/maketranslatedmigrations.py como

#coding: utf-8

from django.core.management.base import BaseCommand
from django.core.management.commands.makemigrations import Command as MakeMigrations


class Command(MakeMigrations):
    leave_locale_alone = True
    can_import_settings = True

    def handle(self, *app_labels, **options):
        super(Command, self).handle(*app_labels, **options)

Y luego puede usarlo exactamente igual que las migraciones originales.

PD: No olvides agregar archivos __init__.py cualquier lugar de la ruta.

Answer 2

El boleto que ChillarAnand menciona es muy útil, pero al final del registro de cambios, no me di cuenta de si se había corregido o no, o se había corregido en la versión más reciente de Django.

Entonces, debido a que no encontré ninguna solución para Django 1.9.13, agregué un pequeño truco a settings.py :

if ''makemigrations'' in sys.argv:
    USE_I18N = False
    USE_L10N = False

No es elegante, pero funciona bien.

Answer 3

He escrito un módulo personalizado para ese propósito

Todo lo que necesita es guardarlo en algunos utils / models.db y en todos sus modelos en lugar de hacerlo from django.db import models escribir from utils import models

Si alguien está interesado en él, puedo escribir un componente y publicarlo en pypi

UPD: prueba esto https://github.com/FeroxTL/django-migration-control

# models.py

# -*- coding: utf-8 -*-
from types import FunctionType
from django.db import models


class NoMigrateMixin(object):
    """
    Позволяет исключить из миграций различные поля
    """
    def deconstruct(self):
        name, path, args, kwargs = super(NoMigrateMixin, self).deconstruct()
        kwargs.pop(''help_text'', None)
        kwargs.pop(''verbose_name'', None)
        return name, path, args, kwargs


# =============================================================================
# DJANGO CLASSES
# =============================================================================

for name, cls in models.__dict__.items():
    if isinstance(cls, type):
        if issubclass(cls, models.Field):
            # Поля
            globals()[name] = type(name, (NoMigrateMixin, cls), {})
        else:
            # Всякие менеджеры
            globals()[name] = cls
    elif isinstance(cls, FunctionType):
        # Прочие функции
        globals()[name] = cls

Answer 4

Para evitar migraciones innecesarias puede hacer lo siguiente:

1. Campo de subclase que causa migración
2. Escribe el método de deconstrucción personalizado dentro de ese campo
3. Lucro

Ejemplo:

from django.db import models

class CustomCharField(models.CharField):  # or any other field

    def deconstruct(self):
        name, path, args, kwargs = super(CustomCharField, self).deconstruct()
        # exclude all fields you dont want to cause migration, my example below:
        if ''help_text'' in kwargs:
            del kwargs[''help_text'']
        if ''verbose_name'' in kwargs:
            del kwargs[''verbose_name'']
        return name, path, args, kwargs

Espero que ayude

Answer 5

Puedes aplastarlo con la migración anterior , claro.

O si no desea enviar esas migraciones en absoluto, puede anular el makemigrations y migrate al poner esto en management/commands/makemigrations.py en su aplicación:

from django.core.management.commands.makemigrations import Command
from django.db import models

IGNORED_ATTRS = [''verbose_name'', ''help_text'', ''choices'']

original_deconstruct = models.Field.deconstruct

def new_deconstruct(self):
  name, path, args, kwargs = original_deconstruct(self)
  for attr in IGNORED_ATTRS:
    kwargs.pop(attr, None)
  return name, path, args, kwargs

models.Field.deconstruct = new_deconstruct

Answer 6

Este boleto abordó el problema.

Si ha cambiado solo help_text & django genera una nueva migración; luego puede aplicar los cambios de la migración más reciente a la migración anterior y eliminar la migración más reciente.

Simplemente cambie help_text en la migración anterior a help_text presente en la última migración y elimine el último archivo de migración. Asegúrese de eliminar el archivo *.pyc correspondiente, si está presente. De lo contrario, se generará una excepción.