If you do what Simon and I suggest, you should get the result you just described. If you don’t, please explain what happens.
Within a transaction — and disabling autocommit means you’re within a transaction — transaction.atomic() uses savepoints. Note that in Django 1.6, after set_autocommit(False), you couldn’t use transaction.atomic(). That was fixed in 1.8 (I think). -- Aymeric. > On 04 Mar 2016, at 21:21, Tore Lundqvist <t...@mima.x.se> wrote: > > Hi, Simon > > No, I would need to wrap everything i a atomic block to start the transaction > and it's only when that outermost atomic block exits that I actually get a > commit the nested ones just makes save point. > > /Tore > > Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes: > Hi Tore, > > Is there a reason you can't simply wrap your updates in a > `transaction.atomic()` blocks? > > You should be able to avoid deadlocks and control exactly when data is > written to disk > with this construct. > > Simon > > Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit : > Reply to comments in ticket: > https://code.djangoproject.com/ticket/26323#comment:10 > <https://code.djangoproject.com/ticket/26323#comment:10> > > Hi, > > @Aagustin: I get your point but in the code I'm working on there is a lot of > transaction.commit(), not to handle transactions but to manage when data is > written to disk and to avoid deadlocks. Running in autocommit mode does not > work, its slow and sometimes the commits is used to save in a known good > state. So I disable autocommit with transaction.set_autocommit(False) and run > the code with explicit commits in it and than turn autocommit on again. > > The documentation for set_autocommit says "Once you turn autocommit off, you > get the default behavior of your database adapter, and Django won’t help > you." That is what I want and thats way I think that the > TransactionManagementError should not de raise if your not using atomic > blocks. > > -- > 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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/a6077f33-1113-4767-828c-8b2c0c77bd78%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/a6077f33-1113-4767-828c-8b2c0c77bd78%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/838C906E-6290-4C70-9E4C-8E6E7832CCF1%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
