Here we cover details about more advanced database setups that might impact how you use triggers.
Triggers are migrated for multiple database just like models. If you define a
custom router, triggers will be installed based on allow_migrate
.
See the the Django docs on multiple databases
for more info.
Warning
If you migrate triggers and afterwards change the behavior of the router's
allow_migrate
, you risk having orphaned triggers installed on tables.
The management commands and core installation functions work the same way,
targetting an individual database like Django's migrate
command.
Each command can be supplied with a -d
or --database
option.
For example, python manage.py pgtrigger install --database other
will
install all of the triggers on the other
database.
If allow_migrate
ignores a particular model for a database, the
installation status will show as UNALLOWED
when using
python manage.py pgtrigger ls
.
Note
If you've configured settings.INSTALL_ON_MIGRATE
, triggers will
be installed for the same database as the migrate
command.
Dynamic runtime functions pgtrigger.ignore, pgtrigger.schema, and
pgtrigger.constraints operate on all postgres databases at once
unless the databases
argument is provided.
There are two common ways of using Postgres schemas in Django, both of which
work with django-pgtrigger
:
- Create a database in
settings.DATABASES
for each schema, configuring thesearch_path
in theOPTIONS
. - Use an app like django-tenants
to dynamically set the
search_path
for a single database.
When using the first approach, use the multi-database support detailed in
the previous section. For the second approach, django-pgtrigger
comes with the following functionality to dynamically set the search_path
:
Pass
--schema
(-s
) arguments for management commands. For example, this setssearch_path
tomyschema,public
and shows trigger installation status relative to those schemas:python manage.py pgtrigger ls -s my_schema -s public
Programmatically set the search path with pgtrigger.schema. For example, this sets the
search_path
tomyschema,public
:with pgtrigger.schema("myschema", "public"): # seach_path is set to "myschema,public". Any nested invocations of # pgtrigger.schema will append to the path if not currently # present
Note
If you find yourself wrapping the django-pgtrigger
API with pgtrigger.schema,
open an issue and let us know about your use case. We may consider making it a
first-class citizen in the API if it's common.
The final thing to keep in mind with multi-schema support is that pgtrigger.ignore uses a special Postgres function for ignoring triggers that's installed under the public schema. The function is always referenced with a fully-qualified name.
If you don't use the public schema, configure the schema with
settings.PGTRIGGER_SCHEMA
. Setting this to None
uses a relative path when
installing and calling the function.
django-pgtrigger
supports tables that use Postgres table partitioning with no additional configuration.
Note
Row-level triggers are only available for partitioned tables in Postgres 13 and above. Triggers cannot be installed or uninstalled on a per-partition basis. Installing a trigger on a partitioned table installs it for all partitions.