django-pgtrigger

django-pgtrigger copied to clipboard

Version 3 integrates django-pgtrigger with the Django migration system, along with several other superficial updates. Version 4 changes the behavior of using triggers in multi-database environments.

TL;DR Most users can do python manage.py makemigrations after upgrading with no problems. If you have triggers registered to third party models or use a mutli-database (or multi-schema) setup, read below for all key updates.

Integration with Django migrations (Version 3)

All triggers now appear in migrations when running python manage.py makemigrations. Triggers from version 2 will appear as new AddTrigger operations and succeed when running migrate even if previously installed. Remember, however, that triggers will be deleted if the migrations are reversed.

Almost all users can simply run python manage.py makemigrations after upgrading. If, however, you have triggers on third-party models or many-to-many default "through" models, use these instructions to migrate them:

1. If you already ran python manage.py makemigrations, delete any new migrations made for these third-party apps.
2. Declare proxy models for the third-party or default many-to-many "through" models, register triggers in the Meta.triggers or those, and call python manage.py makemigrations. See examples in the "Advanced Installation" section of the docs here
3. Warning Declaring proxy models will rename old triggers, leaving them in an orphaned state since they weren't previously managed by migrations. Ensure these old triggers are removed by doing any of the following: a. Make a migrations.RunPython operation at the end of your migration or in a new data migration that does call_command("pgtrigger", "prune"). Note that call_command is imported from django.core.management. b. OR run python manage.py pgtrigger prune after your deployment is complete c. OR set settings.PGTRIGGER_INSTALL_ON_MIGRATE to True for a short period of time in your settings. This will automatically prune those old triggers after deployment, and you can turn this setting back to False later.

If you'd like to keep the legacy installation behavior, set PGTRIGGER_MIGRATIONS to False to turn off trigger migrations and set PGTRIGGER_INSTALL_ON_MIGRATE to True so that triggers are always installed at the end of python manage.py migrate.

Dropping of django-pgconnection dependency (Version 3)

pgtrigger.ignore previously required that django-pgconnection was used to configure the settings.DATABASES setting. django-pgconnection is no longer needed, and settings.DATABASES no longer needs to be wrapped in order for pgtrigger.ignore to function properly.

New Meta.triggers syntax (Version 2.5)

Version 2.5 introduced the ability to register triggers on your model's Meta.triggers list. User can still use pgtrigger.register to register triggers programmatically.

Adjustments to multi-database support (Version 4)

Previously triggers were installed to databases based on the db_for_write method of the database router. Multiple database support now mimics Django's and follows the allow_migrate method of the database router.

What this means:

1. Triggers are installed on all databases unless allow_migrate says otherwise. This holds true when running migrations and when running any of the management commands such as manage.py pgtrigger install.
2. If you use the legacy settings.PGTRIGGER_INSTALL_ON_MIGRATE to install triggers after migrations, it will install triggers to the same database provided to manage.py migrate or the default database if none is provided.
3. All management commands take a --database argument to target an individual database now.
4. manage.py pgtrigger ls will show UNALLOWED as the installation status of a trigger if it's not allowed to be installed on a database

Multi-schema support (Version 4)

Multi-schema support is now a first-class citizen. See the docs here

These changes are great @wesleykendall - thanks very much

One thing we encountered was that a couple of trigger had a name change so after migrating the old triggers still existed. Specially these were for some m2m through models I created new proxy models for as part of these changes. We had to manually run a prune to clean them up. Might be worth mentioning this in the upgrade notes?

@davecoates thanks so much for bringing this to my attention. I will update the upgrade notes here and in the official docs today. It totally slipped my mind that the trigger names would change, causing a need to prune old ones that weren't tracked in migrations. My apologies if this caused you trouble or errors in your application.

BTW I'm integrating django-pgtrigger with Django's check framework. I'm planning to add a special check to the manage.py check --deploy command while also exposing a pgtrigger check command. It will fail if there are any triggers that are outdated, uninstalled, or need to be pruned. While I don't plan to do a breaking change like this release again in the future, I hope this check will be helpful to avoid situations like what you encountered. Feedback is welcome!

Added a third bullet point to the migration notes and also updated it in the FAQ in #94