[1.7.x] Fixed #22863: Improve clarity of makemigrations for non-db params
This commit is contained in:
parent
30d8b95139
commit
bfe5f72c7e
|
@ -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(),
|
||||
|
|
|
@ -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
|
||||
---------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue