On Sat, 20 Nov 2021 at 14:21, Florian Apolloner
wrote:
> I even have a possible fix for that, but it requires us to rewrite
> middlewares again :/
>
This is the third time this has come up (the middleware rewrite I mean)
Rule of Threes. We need a DjangoCon, so we can draft a DEP. :)
>
--
You
Hi Aymeric,
On Saturday, November 20, 2021 at 12:39:17 PM UTC+1 Aymeric Augustin wrote:
> I'm not trying to disagree for the sake of disagreement; I'm just trying
> to bring some contextual awareness and avoid the "core devs say
> ATOMIC_REQUESTS is bad" effect. I hope we can agree on this?
>
Hello,
> On 18 Nov 2021, at 11:11, Florian Apolloner wrote:
>
> FWIWI I always recommend disabling ATOMIC_REQUESTS and using transactions as
> needed :)
Investing engineers' time into evaluating the exact transactional integrity
requirements of every view may be appropriate in some
On Wednesday, November 17, 2021 at 11:09:58 PM UTC+1 Adam Johnson wrote:
> FWIW I always recommend enabling ATOMIC_REQUESTS and ensuring transactions
> are used by default in other code paths such as background tasks.
>
FWIWI I always recommend disabling ATOMIC_REQUESTS and using transactions
Hi Adam
I will check into it.
IMO using ATOMIC_REQUESTS is an antipattern. Views shouldn't know anything
about the database. Services should handle all persistence related stuff
and that's why transactions should only be used when necessary.
Best!
Klemen
sreda, 17. november 2021 ob 23:09:58
Hi Klemen
We recently changed atomic() to mark when it is created by the test runner
for this ticket: https://code.djangoproject.com/ticket/33161 . This was for
special case logic around the 'durable' flag to atomic().
Perhaps the newly added tracking can also be used for the check in
Hi!
I noticed dangerous behaviour with testing and usage of *select_for_update *in
transactions.
This "feature" crashed some parts of production in our company.
The "feature" I am talking about, is that test runner wraps all tests in a
transaction. If you use *select_for_update* you have to wrap
