Thanks for the suggestion! I have been thinking of workarounds with multiple db aliases and it would solve the problem I described but in reality the code I'm working with is much more complex and has around 400 explicit commits. It all worked great in Django 1.4 but since we upgraded to 1.8 (and got the new transaction management) I have been forced to make ugly workarounds and patch Django this time.
Den lördag 5 mars 2016 kl. 19:41:59 UTC+1 skrev jdunck: > > I've had this scenario before - you have two interleaving units of work > (through composition of code from different sources or concerns). You want > progress recorded for one unit of work, but perhaps not the other. Without > django, you'd have two open connections. In my experience the simplest way > to accommodate this is to have two DB aliases pointed at the same DB. Set > one to be a test mirror of the other. Use different aliased connections > for the two concerns. Then you can use atomic (as suggested and typical). > > On Fri, Mar 4, 2016 at 2:11 PM, Tore Lundqvist <t...@mima.x.se > <javascript:>> wrote: > >> 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> 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. >>> To post to this group, send email to django-d...@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/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-develop...@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/79611d30-21e0-45bc-8ab7-8754a39db4fc%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/79611d30-21e0-45bc-8ab7-8754a39db4fc%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/057c7bd1-59e4-4adf-a7b8-04740ddc69b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
