Hi Tore,
You should be able to get what you want be replacing your commits by
connection.cursor.execute("commit"); transaction.rollback()
or equivalents (caveat: untested).
This looks like a very hackish thing to do, code I wouldn't put in production.
And it should.
Shai.
On Saturday 05 March 2016 21:21:27 Tore Lundqvist wrote:
> 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).
> >>>
> >>>
> >>> 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-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-8
> >> ab7-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.
