diff options
| author | Mariusz Felisiak <felisiak.mariusz@gmail.com> | 2022-07-20 07:34:21 +0200 |
|---|---|---|
| committer | Mariusz Felisiak <felisiak.mariusz@gmail.com> | 2022-07-26 11:41:19 +0200 |
| commit | a1e9e9abc592b8f44fa798c6e4e225b1a04f757c (patch) | |
| tree | 7c0713759aa50f55b639433675015e385c434e04 /docs/topics/migrations.txt | |
| parent | c773d5794eb425c4836c726bdf6e1e742c94e9c0 (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.txt | 50 |
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 |
