Why does Django make migrations for help_text and verbose_name changes?

PythonDjangoDatabase MigrationDjango 1.7Django 1.9

Python Problem Overview


When I change help_text or verbose_name for any of my model fields and run python manage.py makemigrations, it detects these changes and creates a new migration, say, 0002_xxxx.py.

I am using PostgreSQL and I think these changes are irrelevant to my database (I wonder if a DBMS for which these changes are relevant exists at all).

Why does Django generate migrations for such changes? Is there an option to ignore them?

Can I apply the changes from 0002_xxxx.py to the previous migration (0001_initial.py) manually and safely delete 0002_xxxx.py?

Is there a way to update previous migration automatically?

Python Solutions


Solution 1 - Python

You can squash it with the previous migration, sure.

Or if you don't want to output those migrations at all, you can override the makemigrations and migrate command by putting this in management/commands/makemigrations.py in your app:

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

Solution 2 - Python

This ticket addressed the problem.

If you have changed only help_text & django generates a new migration; then you can apply changes from latest migration to previous migration and delete the latest migration.

Just change the help_text in the previous migration to help_text present in latest migration and delete the latest migration file. Make sure to remove corresponding *.pyc file if it is present. Otherwise an exception will be raised.

Solution 3 - Python

To avoid unnecessary migrations You can do as follows:

  1. Subclass field that causes migration
  2. Write custom deconstruct method inside that field
  3. Profit

Example:

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

Hope that helps

Solution 4 - Python

As @ChillarAnand noted there is a ticket solving this issue but until now (django 1.9.1) the migrations commands were not fixed.

The least intrusive way of fixing it is to create your own maketranslatedmigrations command in <your-project>/management/commands/maketranslatedmigrations.py as

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

And then you can use it exactly the same as original makemigrations.

P.S. Don't forget to add __init__.py files everywhere on the path

Solution 5 - Python

I have written custom module for that purpose

All you need is to save it in some utils/models.db and in all your models instead of from django.db import models write from utils import models

If somebody is interested in it I can write a component and publish it on pypi

UPD: try this 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

Solution 6 - Python

From Django 2.X, using ugettext_lazy instead of ugettext or gettext fixes it.

Solution 7 - Python

Stop to generate migrations files when changes verbose_name or verbose_name_plural in any of your model fields.

In a new file like src/monkey_patching/django/db/migrations/operations/change_model_options.py add this:

from django.db.migrations.operations import models

models.AlterModelOptions.ALTER_OPTION_KEYS = [    "base_manager_name",    "default_manager_name",    "get_latest_by",    "managed",    "ordering",    "permissions",    "default_permissions",    "select_on_save",    # "verbose_name",    # "verbose_name_plural",]

Tested in django 1.11.10.

Solution 8 - Python

The ticket that ChillarAnand mentions is very helpfull, but at final of changelog, I did not realize if it was fixed or not, or it was fixed in newest version of Django.

So, due to I did not found any solution for Django 1.9.13, I added a little hack to settings.py:

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

Not elegant, but it works ok.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionutapyngoView Question on Stackoverflow
Solution 1 - PythonNick RetallackView Answer on Stackoverflow
Solution 2 - PythonPandikunta Anand ReddyView Answer on Stackoverflow
Solution 3 - Pythonuser3025188View Answer on Stackoverflow
Solution 4 - PythonkatomasoView Answer on Stackoverflow
Solution 5 - PythonFeroxTLView Answer on Stackoverflow
Solution 6 - PythonkogexoView Answer on Stackoverflow
Solution 7 - PythonLeonardo RamírezView Answer on Stackoverflow
Solution 8 - PythonnashualdView Answer on Stackoverflow