Re: [psycopg] Nested transactions support for code composability - Mailing list psycopg

From Daniel Fortunov
Subject Re: [psycopg] Nested transactions support for code composability
Date
Msg-id CAH1rg6YyNZm+C7pAJgzfy1g3koXFzCMek-GMTjc8i0_oZNcnHQ@mail.gmail.com
Whole thread Raw
In response to Re: [psycopg] Nested transactions support for code composability  (Christophe Pettus <xof@thebuild.com>)
Responses Re: [psycopg] Nested transactions support for code composability  (Christophe Pettus <xof@thebuild.com>)
Re: [psycopg] Nested transactions support for code composability  (Adrian Klaver <adrian.klaver@aklaver.com>)
List psycopg
On 16 January 2017 at 23:29, Christophe Pettus <xof@thebuild.com> wrote:

> On Jan 16, 2017, at 15:26, Daniel Fortunov <psycopg-list@danielfortunov.com> wrote:
>
> I'd like to implement support for nested transactions in psycopg2 using a context manager that internally uses postgres savepoints to implement the ability to nest transactions within each other, with sensible commit and rollback semantics.

You can see two existing examples of this, based on Django.  Django implements the @atomic() decorator, which was based on my @xact() decorator:

        https://github.com/Xof/xact

They can almost certainly be eased out of the Django infrastructure easily enough!

Yes, this is exactly what I'm talking about.

So what am I missing? Doesn't anyone find the need for this outside of Django?!

How do people use transactions in (non-Django) library code?

Daniel

psycopg by date:

Previous
From: Aryeh Leib Taurog
Date:
Subject: Re: [psycopg] speed concerns with executemany()
Next
From: Christophe Pettus
Date:
Subject: Re: [psycopg] Nested transactions support for code composability