mirror of
https://github.com/django/django.git
synced 2025-10-23 21:59:11 +00:00
Refs #27236 -- Reverted "Refs #27236 -- Added generic mechanism to handle the deprecation of migration operations."
This reverts commit 41019e48bb.
This commit is contained in:
@@ -128,18 +128,18 @@ The code below is equivalent to the code above::
|
||||
|
||||
.. _field-checking:
|
||||
|
||||
Field, model, manager, migration, and database checks
|
||||
-----------------------------------------------------
|
||||
Field, model, manager, and database checks
|
||||
------------------------------------------
|
||||
|
||||
In some cases, you won't need to register your check function -- you can
|
||||
piggyback on an existing registration.
|
||||
|
||||
Fields, models, model managers, migrations, and database backends all implement
|
||||
a ``check()`` method that is already registered with the check framework. If
|
||||
you want to add extra checks, you can extend the implementation on the base
|
||||
class, perform any extra checks you need, and append any messages to those
|
||||
generated by the base class. It's recommended that you delegate each check to
|
||||
separate methods.
|
||||
Fields, models, model managers, and database backends all implement a
|
||||
``check()`` method that is already registered with the check framework. If you
|
||||
want to add extra checks, you can extend the implementation on the base class,
|
||||
perform any extra checks you need, and append any messages to those generated
|
||||
by the base class. It's recommended that you delegate each check to separate
|
||||
methods.
|
||||
|
||||
Consider an example where you are implementing a custom field named
|
||||
``RangedIntegerField``. This field adds ``min`` and ``max`` arguments to the
|
||||
@@ -194,10 +194,6 @@ the only difference is that the check is a classmethod, not an instance method::
|
||||
# ... your own checks ...
|
||||
return errors
|
||||
|
||||
.. versionchanged:: 4.2
|
||||
|
||||
Migration checks were added.
|
||||
|
||||
Writing tests
|
||||
-------------
|
||||
|
||||
|
||||
@@ -503,56 +503,6 @@ database migrations such as ``__init__()``, ``deconstruct()``, and
|
||||
which reference the field exist. For example, after squashing migrations and
|
||||
removing the old ones, you should be able to remove the field completely.
|
||||
|
||||
.. _migrations-removing-operation:
|
||||
|
||||
Considerations when removing migration operations
|
||||
=================================================
|
||||
|
||||
.. versionadded:: 4.2
|
||||
|
||||
Removing custom operations from your project or third-party app will cause a
|
||||
problem if they are referenced in old migrations.
|
||||
|
||||
To help with this situation, Django provides some operation attributes to
|
||||
assist with operation deprecation using the :doc:`system checks framework
|
||||
</topics/checks>`.
|
||||
|
||||
Add the ``system_check_deprecated_details`` attribute to your operation similar
|
||||
to the following::
|
||||
|
||||
class MyCustomOperation(Operation):
|
||||
system_check_deprecated_details = {
|
||||
"msg": (
|
||||
"MyCustomOperation has been deprecated. Support for it "
|
||||
"(except in historical migrations) will be removed in "
|
||||
"Django 5.1."
|
||||
),
|
||||
"hint": "Use DifferentOperation instead.", # optional
|
||||
"id": "migrations.W900", # pick a unique ID for your operation.
|
||||
}
|
||||
|
||||
After a deprecation period of your choosing (two or three feature releases for
|
||||
operations in Django itself), change the ``system_check_deprecated_details``
|
||||
attribute to ``system_check_removed_details`` and update the dictionary similar
|
||||
to::
|
||||
|
||||
class MyCustomOperation(Operation):
|
||||
system_check_removed_details = {
|
||||
"msg": (
|
||||
"MyCustomOperation has been removed except for support in "
|
||||
"historical migrations."
|
||||
),
|
||||
"hint': "Use DifferentOperation instead.",
|
||||
"id": "migrations.E900", # pick a unique ID for your operation.
|
||||
}
|
||||
|
||||
You should keep the operation's methods that are required for it to operate in
|
||||
database migrations such as ``__init__()``, ``state_forwards()``,
|
||||
``database_forwards()``, and ``database_backwards()``. Keep this stub operation
|
||||
for as long as any migrations which reference the operation exist. For example,
|
||||
after squashing migrations and removing the old ones, you should be able to
|
||||
remove the operation completely.
|
||||
|
||||
.. _data-migrations:
|
||||
|
||||
Data Migrations
|
||||
|
||||
Reference in New Issue
Block a user