summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorAndrew Godwin <andrew@aeracode.org>2014-06-19 23:40:59 -0700
committerAndrew Godwin <andrew@aeracode.org>2014-06-19 23:41:32 -0700
commit9f4852f649fad459a451995c4a17a7d8db5972c9 (patch)
treec8e488e4bf84d86cb0c421e89c7e91e3d1fb39ee /docs
parentd862fae5bbfb52ab7aeaad5a59b3d8b27b30c8f9 (diff)
Fixed #22863: Improve clarity of makemigrations for non-db params
Diffstat (limited to 'docs')
-rw-r--r--docs/topics/migrations.txt6
1 files changed, 6 insertions, 0 deletions
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index a4fc5c9e52..b63ab48ecf 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
---------------