diff options
| author | Markus Holtermann <info@markusholtermann.eu> | 2014-10-07 01:53:21 +0200 |
|---|---|---|
| committer | Loic Bistuer <loic.bistuer@gmail.com> | 2014-10-09 22:41:27 +0700 |
| commit | 71988ed953131908fa2a1ba9fac294cedaa6e6c9 (patch) | |
| tree | 6100d3bd52bf3fc3186536f4e64664b2c9c1b34a /docs | |
| parent | e31be40f163e7d478946530acb1068c6deadb845 (diff) | |
[1.7.x] Fixed #23609 -- Fixed IntegrityError that prevented altering a NULL column into a NOT NULL one due to existing rows
Thanks to Simon Charette, Loic Bistuer and Tim Graham for the review.
Backport of f633ba778d from master
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/ref/migration-operations.txt | 16 | ||||
| -rw-r--r-- | docs/releases/1.7.1.txt | 4 |
2 files changed, 18 insertions, 2 deletions
diff --git a/docs/ref/migration-operations.txt b/docs/ref/migration-operations.txt index e377a251f4..e5c21ea072 100644 --- a/docs/ref/migration-operations.txt +++ b/docs/ref/migration-operations.txt @@ -137,7 +137,7 @@ or if it is temporary and just for this migration (``False``) - usually because the migration is adding a non-nullable field to a table and needs a default value to put into existing rows. It does not effect the behavior of setting defaults in the database directly - Django never sets database -defaults, and always applies them in the Django ORM code. +defaults and always applies them in the Django ORM code. RemoveField ----------- @@ -153,16 +153,28 @@ from any data loss, which of course is irreversible). AlterField ---------- -.. class:: AlterField(model_name, name, field) +.. class:: AlterField(model_name, name, field, preserve_default=True) Alters a field's definition, including changes to its type, :attr:`~django.db.models.Field.null`, :attr:`~django.db.models.Field.unique`, :attr:`~django.db.models.Field.db_column` and other field attributes. +The ``preserve_default`` argument indicates whether the field's default +value is permanent and should be baked into the project state (``True``), +or if it is temporary and just for this migration (``False``) - usually +because the migration is altering a nullable field to a non-nullable one and +needs a default value to put into existing rows. It does not effect the +behavior of setting defaults in the database directly - Django never sets +database defaults and always applies them in the Django ORM code. + Note that not all changes are possible on all databases - for example, you cannot change a text-type field like ``models.TextField()`` into a number-type field like ``models.IntegerField()`` on most databases. +.. versionchanged:: 1.7.1 + + The ``preserve_default`` argument was added. + RenameField ----------- diff --git a/docs/releases/1.7.1.txt b/docs/releases/1.7.1.txt index 68370dd44a..70535b8161 100644 --- a/docs/releases/1.7.1.txt +++ b/docs/releases/1.7.1.txt @@ -108,3 +108,7 @@ Bugfixes type (byte string) on Python 3 (:ticket:`23333`). * :djadmin:`makemigrations` can now serialize timezone-aware values (:ticket:`23365`). + +* Added a prompt to the migrations questioner when removing the null constraint + from a field to prevent an IntegrityError on existing NULL rows + (:ticket:`23609`). |
