Why is DSH not using SQL triggers instead of post_save ?

[elnygren]

It seems like django-simple-history is solving the problem of maintaining something commonly known as a "history table". This is usually solved quite elegantly at the SQL level using triggers (https://www.postgresql.org/docs/13/sql-createtrigger.html).

Some notes on why this is a good approach:

• SQL triggers automatically run inside the transaction where they we're triggered in
• post_save does not run in the same transaction as Model.save automatically
• SQL triggers also handle situations where someone bypasses Django ORM or does anything that bypasses post_save
  • bulk_create, bulk_delete, .update etc. are all solved by SQL triggers
  • manual SQL through django or even directly at the DB are also solved by SQL triggers

So it at least seems that SQL triggers are superior and would save a lot of python code here.
Could django-simple-history just generate the correct trigger(s) instead of using post_save ?

[jeking3]

Django has some pretty nonsensical transactional behavior; I usually enable global request transactions in my projects. Request processing should succeed or fail, signals and all. So that can mitigate bullet #2; I would suggest if people want atomicity with history they do the same.

As for using the database, is there a solution for every database the library claims to support? What you suggested is database-specific behavior; there is already some in the as_of query processing and it's not awesome to maintain...