| 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: | Whole Thread | Raw Message | 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() |