From bfe5f72c7ee4ecec374af9a52c320c019abfc338 Mon Sep 17 00:00:00 2001 From: Andrew Godwin Date: Thu, 19 Jun 2014 23:40:59 -0700 Subject: [PATCH] [1.7.x] Fixed #22863: Improve clarity of makemigrations for non-db params --- django/core/management/commands/migrate.py | 2 +- docs/topics/migrations.txt | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/django/core/management/commands/migrate.py b/django/core/management/commands/migrate.py index aab656bb2e3..6432a4c3f71 100644 --- a/django/core/management/commands/migrate.py +++ b/django/core/management/commands/migrate.py @@ -132,7 +132,7 @@ class Command(BaseCommand): self.stdout.write(self.style.MIGRATE_HEADING("Running migrations:")) if not plan: if self.verbosity >= 1: - self.stdout.write(" No migrations needed.") + self.stdout.write(" No migrations to apply.") # If there's changes that aren't in migrations yet, tell them how to fix it. autodetector = MigrationAutodetector( executor.loader.project_state(), diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt index a4fc5c9e52a..b63ab48ecf5 100644 --- a/docs/topics/migrations.txt +++ b/docs/topics/migrations.txt @@ -60,6 +60,12 @@ Migrations will run the same way on the same dataset and produce consistent results, meaning that what you see in development and staging is, under the same circumstances, exactly what will happen in production. +Django will make migrations for any change to your models or fields - even +options that don't affect the database - as the only way it can reconstruct +a field correctly is to have all the changes in the history, and you might +need those options in some data migrations later on (for example, if you've +set custom validators). + Backend Support ---------------