Improve docs around deconstruction/serialisation (refs #22337)

   In addition, if your class provides local file storage, it must override

   the ``path()`` method.

#. Your storage class must be :ref:`deconstructible <custom-deconstruct-method>`

   so it can be serialized when it's used on a field in a migration. As long

   as your field has arguments that are themselves

   :ref:`serializable <migration-serializing>`, you can use the

   ``django.utils.deconstruct.deconstructible`` class decorator for this

   (that's what Django uses on FileSystemStorage).

Your custom storage system may override any of the storage methods explained in

:doc:`/ref/files/storage`, but you **must** implement the following methods:

fields, including ``DecimalField`` and ``DateField``, override it and show how

to call the method on the superclass and simply add or remove extra arguments.

This also means that all arguments to fields must themselves be serializable;

to see what we consider serializable, and to find out how to make your own

classes serializable, read the

:ref:`migration serialization documentation <migration-serializing>`.

Calling custom ``QuerySet`` methods from the ``Manager``

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

this has the added advantage that your initial data will not need updating

every time you change the schema.

deconstruct() and serializability

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Django now requires all Field classes and all of their constructor arguments

to be serializable. If you modify the constructor signature in your custom

Field in any way, you'll need to implement a deconstruct() method;

we've expanded the custom field documentation with :ref:`instructions

on implementing this method <custom-field-deconstruct-method>`.

The requirement for all field arguments to be

:ref:`serializable <migration-serializing>` means that any custom class

instances being passed into Field constructors - things like custom Storage

subclasses, for instance - need to have a :ref:`deconstruct method defined on

them as well <custom-deconstruct-method>`, though Django provides a handy

class decorator that will work for most applications.

App-loading changes

~~~~~~~~~~~~~~~~~~~

Django will write out the value as an instantiation of your class with the

given arguments, similar to the way it writes out references to Django fields.

As long as all of the arguments to your class' constructor are themselves

serializable, you can just use the ``@deconstructible`` class decorator

from ``django.utils.deconstruct`` to add the method::

    from django.utils.deconstruct import deconstructible

    @deconstructible

    class MyCustomClass(object):

        def __init__(self, foo=1):

            ...

The decorator adds logic to capture and preserve the arguments on their

way into your constructor, and then returns those arguments exactly when

deconstruct() is called.

Upgrading from South

--------------------