This package allows deprecating Django model fields and enables their removal in a backwards-compatible manner. It's particularly useful for maintaining migration consistency during rolling deployments where multiple application versions might run in parallel. The current version is 0.2.3, and releases are driven by changes merged to the main branch.
pip install django-deprecate-fieldsVerified import paths — ran on the pinned version, not inferred.
To deprecate a model field, import `deprecate_field` and wrap the existing field definition with it. After this, run `makemigrations`. The package automatically handles making the field nullable. The `return_instead` argument can be used to specify a value or callable to return when the deprecated field is accessed.
Run `python manage.py makemigrations` after wrapping a field with `deprecate_field`, and then apply the migration.
Add `DEPRECATED_FIELD_STRICT = True` to your Django `settings.py` file to convert access warnings into exceptions.
Follow the two-step removal process: 1. Deprecate field, `makemigrations`, deploy. 2. Remove field from model, `makemigrations`, deploy.
Add `DEPRECATE_FIELD_CUSTOM_MIGRATION_COMMAND = {"your_custom_command"}` to your Django `settings.py`.While the exact fix depends on the underlying cause of the 'noisy errors,' users should check the `django-deprecate-fields` GitHub issues for specific resolutions or workarounds. It may involve adjusting Django settings or ensuring correct application of `deprecate_field`.
To resolve this safely, use `django-deprecate-fields` in a two-phase deployment: first, wrap the field definition in `deprecate_field()` and deploy, allowing all running instances to use the deprecated (but still existing) column. After ensuring all old code references are gone and a new migration makes the column nullable, then in a subsequent deployment, remove the field entirely from the model and apply a migration to drop the column from the database.
When adding a new non-nullable field, ensure a two-phase deployment. Initially, add the field as nullable (or with a default) and deploy. Once all application instances are running the code aware of the new field, then update the field to be non-nullable (if desired) in a subsequent deployment. While `django-deprecate-fields` is primarily for *removing* fields, its principles of phased deployment apply to safely adding non-nullable fields as well.