innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

[1.7.x] Fixed #22863: Improve clarity of makemigrations for non-db params

This commit is contained in:
Andrew Godwin 2014-06-19 23:40:59 -07:00
parent 30d8b95139
commit bfe5f72c7e
2 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
django/core/management/commands/migrate.py
View File

@ -132,7 +132,7 @@ class Command(BaseCommand):
self.stdout.write(self.style.MIGRATE_HEADING("Running migrations:")) self.stdout.write(self.style.MIGRATE_HEADING("Running migrations:"))
if not plan: if not plan:
if self.verbosity >= 1: 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. # If there's changes that aren't in migrations yet, tell them how to fix it.
autodetector = MigrationAutodetector( autodetector = MigrationAutodetector(
executor.loader.project_state(), executor.loader.project_state(),

6
docs/topics/migrations.txt
View File

@ -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 results, meaning that what you see in development and staging is, under the
same circumstances, exactly what will happen in production. 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 Backend Support
--------------- ---------------