summaryrefslogtreecommitdiff
path: root/docs/topics/migrations.txt
diff options
context:
space:
mode:
authorMariusz Felisiak <felisiak.mariusz@gmail.com>2022-07-20 07:34:21 +0200
committerMariusz Felisiak <felisiak.mariusz@gmail.com>2022-07-26 11:41:19 +0200
commita1e9e9abc592b8f44fa798c6e4e225b1a04f757c (patch)
tree7c0713759aa50f55b639433675015e385c434e04 /docs/topics/migrations.txt
parentc773d5794eb425c4836c726bdf6e1e742c94e9c0 (diff)
Refs #27236 -- Reverted "Refs #27236 -- Added generic mechanism to handle the deprecation of migration operations."
This reverts commit 41019e48bbf082c985e6ba3bad34d118b903bff1.
Diffstat (limited to 'docs/topics/migrations.txt')
-rw-r--r--docs/topics/migrations.txt50
1 files changed, 0 insertions, 50 deletions
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index 2350ac756c..cf3451a782 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -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