Hi Raphael, This is funny. Just last week I looked into exactly the same thing for audit logging as well. Except that I'm writing multiple audit log events and want to batch them at the end of the transaction in a single bulk_create operation instead of a dozen save() calls.
I haven't gotten anywhere for now. But was considering the thread local approach as well. But then, thread locals and Django are not the nicest combination. Maybe we can come up with an approach together? Cheers Markus On Sun, Oct 10, 2021, at 3:55 PM, Raphael Michel wrote: > Hi everyone, > > I've spent some days thinking about a use case we have internally where > we want to create some database records automatically based on some > other records, think e.g. of an audit log where whenever an instance of > model X is changed, we want to create an instance of model Y as a log > record. Of course, there are *lots* of ways and libraries that allow you > to do this with Django, mostly somehow circling around overriding > `save()` or using the `post_save` signal. > > However, we want to do this in an *aggregated* way, i.e. even if you > add hundreds of model instances in the same transaction, we only want > *one* new line in our audit log to be created. This is impossible with > `save()` or `post_save` alone since we can't know which change is the > "last" that should trigger the audit log to be created. > > I figured a perfect way to do this would be using `save()` or > `post_save` to add the changed model instance to some kind of > thread-local list, and then using `transaction.on_commit` to "schedule" > the aggregation and create the log entries when all changes have been > made. However, this obviously is not a good enough because `on_commit` > runs *after* the `COMMIT` statement and thus we're not guaranteed that > all log entries are persisted to the database. > > So I was wondering if there was potential for a > `transaction.on_before_commit` that works just like > `transaction.on_commit` except that it is executed before the `COMMIT` > statement. I imagine there are lots of other possible uses as well and > without looking into it much deeper, it seems easy enough to implement. > > Does anyone have opinions on whether or not this would be a good > feature to add to Django? Unfortunately it doesn't seem possible to do > this as third-party code (except if we were shipping entire database > backends) so it would need to be an acceptable change to Django to be a > viable option. > > Thanks > Raphael > > -- > You received this message because you are subscribed to the Google > Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/20211010155522.6489b86d%40amara.localdomain. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6cd73b6f-d445-4706-b42a-276ae99213d1%40beta.fastmail.com.
