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 21:32:06 +0700 |
| commit | f633ba778d302c12f4295714a78fa20dff98b39f (patch) | |
| tree | ab84612df40c9f8dedbfe387a28279a42873a6ff /docs | |
| parent | 15d350fbce7807ce85d79ae6e31199039062bcd4 (diff) | |
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.
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 6998bdb574..ef5f2a44d9 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 01edc4c8f5..0d6cd3d3b7 100644 --- a/docs/releases/1.7.1.txt +++ b/docs/releases/1.7.1.txt @@ -106,3 +106,7 @@ Bugfixes * Made :func:`~django.utils.http.urlsafe_base64_decode` return the proper type (byte string) on Python 3 (:ticket:`23333`). + +* 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`). |
