search

imsweb / django-history-triggers

Django management command and middleware for creating and maintaining PostgreSQL audit trail triggers.
BSD 2-Clause "Simplified" License
3 stars 7 forks source link

trigger session defaults #7

Open dcwatson opened 1 year ago

dcwatson commented 1 year ago

Right now, required session fields (session_id, session_date, potentially user_id, etc.) need to be provided when starting a history session, otherwise the triggers will fail. This was by design, so triggers fail loudly without context. However, there are applications with substantial "external" database operations (Django management commands, custom SQL, etc.) that are difficult or impossible to wrap in a history session. For instance, running custom SQL on an SQLite database (where you can't create the necessary user-defined functions in SQL yourself), or using a management command from a third-party Django package.

It would be nice to have a way to specify trigger-level default values for fields. It should be off by default, and the pitfalls of silently recording these defaults should be documented, but it should at least be possible.

It would also be nice to have a way to hook into all manage.py commands, but this will be a separate issue as it will require a PR to Django itself.

dcwatson commented 1 year ago

Shortly after opening this, I remembered that https://docs.djangoproject.com/en/4.1/ref/signals/#connection-created exists and could be used to create a default session per Django connection. That has the benefit of allowing applications to be very explicit about how the default values should work, but doesn't address being able to run raw SQL on SQLite. So I'll leave this open to think about some more.