Re: Proposal for a transaction.on_before_commit

Congratulations! Cheers buddy :) On Wed, Oct 13, 2021, 9:36 PM Shai Berger wrote: > Hi Raphael, > > On Tue, 12 Oct 2021 11:28:20 +0200 > Raphael Michel wrote: > > In our case, "not using savepoint rollbacks any more" would be a > > trade-off that we'd happily make (there are enough other

Re: Proposal for a transaction.on_before_commit

Hi Raphael, On Tue, 12 Oct 2021 11:28:20 +0200 Raphael Michel wrote: > In our case, "not using savepoint rollbacks any more" would be a > trade-off that we'd happily make (there are enough other problems > with savepoints to begin with) You seem to imply that savepoint rollbacks are a very easy

Re: Proposal for a transaction.on_before_commit

Hi, Am Sun, 10 Oct 2021 18:38:55 +0300 schrieb Shai Berger : > Why is a before-commit signal preferable to a vanilla Python > context-manager around the code? Or, if it is in the context of > requests, a middleware? basically mostly because you can forget to put the context manager around it and

Re: Proposal for a transaction.on_before_commit

Hi Aymeric, thank you for the insightful reply. Indeed I have overlooked the issue with savepoints which makes it much more fragile. In our case, "not using savepoint rollbacks any more" would be a trade-off that we'd happily make (there are enough other problems with savepoints to begin with),

Re: Proposal for a transaction.on_before_commit

Hello Raphael, Oh - a use case for django-transaction-signals ;-) I'm bringing up this elaborate joke because you're essentially asking for a "pre-commit" signal here and the README contains a good list of things that can go wrong with

Re: Proposal for a transaction.on_before_commit

Because the scoping of the transactions makes it hard I imagine. A view could start more than one transaction for instance, and one of those might succeed and the other might get rolled back. Thinking more about this, a system like this might get hard to implement. Even if thread locals are

Re: Proposal for a transaction.on_before_commit

Just to clarify the use-case: Why is a before-commit signal preferable to a vanilla Python context-manager around the code? Or, if it is in the context of requests, a middleware? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to

Re: Proposal for a transaction.on_before_commit

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

Proposal for a transaction.on_before_commit

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