From: | Daniel Fortunov <psycopg-list(at)danielfortunov(dot)com> |
---|---|
To: | Christophe Pettus <xof(at)thebuild(dot)com> |
Cc: | psycopg(at)postgresql(dot)org |
Subject: | Re: Nested transactions support for code composability |
Date: | 2017-01-22 16:49:18 |
Message-ID: | CAH1rg6YyNZm+C7pAJgzfy1g3koXFzCMek-GMTjc8i0_oZNcnHQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On 16 January 2017 at 23:29, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>
> > On Jan 16, 2017, at 15:26, Daniel Fortunov <psycopg-list(at)danielfortunov(dot)
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2017-01-22 17:22:49 | Re: Nested transactions support for code composability |
Previous Message | Aryeh Leib Taurog | 2017-01-19 12:23:15 | Re: speed concerns with executemany() |