1
0
mirror of https://github.com/django/django.git synced 2025-06-05 03:29:12 +00:00

[2.2.x] Clarified deconstruct() in Custom Model Field docs.

Backport of 9fd90c4088833855b1ae973e4a66cab09a26f3e6 from master.
This commit is contained in:
David Beitey 2019-03-11 03:14:01 +00:00 committed by Tim Graham
parent 3e565b50a9
commit 282961f553

View File

@ -231,9 +231,10 @@ Field deconstruction
-------------------- --------------------
The counterpoint to writing your ``__init__()`` method is writing the The counterpoint to writing your ``__init__()`` method is writing the
``deconstruct()`` method. This method tells Django how to take an instance :meth:`~.Field.deconstruct` method. It's used during :doc:`model migrations
of your new field and reduce it to a serialized form - in particular, what </topics/migrations>` to tell Django how to take an instance of your new field
arguments to pass to ``__init__()`` to re-create it. and reduce it to a serialized form - in particular, what arguments to pass to
``__init__()`` to re-create it.
If you haven't added any extra options on top of the field you inherited from, If you haven't added any extra options on top of the field you inherited from,
then there's no need to write a new ``deconstruct()`` method. If, however, then there's no need to write a new ``deconstruct()`` method. If, however,
@ -269,8 +270,10 @@ we can drop it from the keyword arguments for readability::
del kwargs["max_length"] del kwargs["max_length"]
return name, path, args, kwargs return name, path, args, kwargs
If you add a new keyword argument, you need to write code to put its value If you add a new keyword argument, you need to write code in ``deconstruct()``
into ``kwargs`` yourself:: that puts its value into ``kwargs`` yourself. You should also omit the value
from ``kwargs`` when it isn't necessary to reconstruct the state of the field,
such as when the default value is being used::
from django.db import models from django.db import models