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

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 ) manualmente y eliminar con seguridad 0002_xxxx.py ?

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

Puedes aplastarlo con la migración anterior , claro.

O si no desea generar esas migraciones en absoluto, puede anular el makemigrations y makemigrations colocando 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 

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 el 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 producirá una excepción.

Para evitar migraciones innecesarias puedes 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

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 /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 los archivos __init__.py cualquier lugar de la ruta.

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 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: intente 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 

El boleto que menciona ChillarAnand es muy útil, pero al final de la lista de cambios, no me di cuenta si estaba arreglado o no, o si estaba arreglado 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.