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

Re: Why can't range function be added in templates?

well my bad, tbh i wasn't shouting, just that caps was mistakenly on. If ever I was shouting then I would be using some words which wouldn't be appealing, :thinking: is bruh noo.. a slang or just an expression came out of shock! , i believe anyways `bruh no` is not a slang, *anyways nvm* On

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

Re: Error in Models Documentation

This is not an error. The identified example does _not_ say that it will "return" those entries. It states it will _exclude_ entries matching either of those two conditions. Likewise, the SQL statement referenced is a negation ("and not") of the condition. This portion of the

Error in Models Documentation

Hello everyone. https://docs.djangoproject.com/en/3.2/ref/models/querysets/#django.db.models.query.QuerySet.exclude The second example mentions that the query will return entries *whose * pub_date* is later than 2005-1-3 **O**R **whose headline is “Hello”.* *But the equivalent SQL statement

Re: Django ORM query syntax enhancement

Hi Adam, I agree with some of your points. however djngo orm query syntax is the main pain point for anyone new to django orm. The reason those packages are not widely used is because most people dont know about them and not about this DEP. And most new users mainly end up learning built in