I don't what all updates to be in one commit each so I can't wrap just the update with a atomic block I would need to have it over a bigger chuck of code. That chunk might call a subrutin that also needs a commit and if I wrap that update in a atomic block that atomic block is nested and results in a save point which is useless.
Den fredag 4 mars 2016 kl. 22:46:30 UTC+1 skrev Aymeric Augustin: > > 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 <javascript:>> > 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 >>> >>> 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 <javascript:>. > To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > 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/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. > > > -- 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/79611d30-21e0-45bc-8ab7-8754a39db4fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
