| From: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
|---|---|
| To: | Daniel Fortunov <postgresql(at)danielfortunov(dot)com> |
| Cc: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, Paolo De Stefani <paolo(at)paolodestefani(dot)it>, Psycopg <psycopg(at)postgresql(dot)org> |
| Subject: | Re: Re: psycopg3 transactions |
| Date: | 2021-10-14 22:16:25 |
| Message-ID: | YWisObvZJNvpihtM@hermes.hilbert.loc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | psycopg |
> We are still "using transactions", just with more precise, more explicit*,
> and more flexible* semantics, represented by a context manager.
>
> Rolling back a transaction is possible by raising a Rollback exception
> within a block.
>
> I hope this answers your question but if not please describe the scenario
> you are thinking about.
Personally, I think the autocommit=False approach is somewhat
safer (more conservative) for the data:
One *always* is inside a transaction, and the default
behaviour is to rollback.
Nothing is by accident automatically committed -- which can
happen with autocommit=True.
I would certainly suggest that a context manager calls
.rollback() during teardown rather than .commit() -- the
context manager cannot know whether actions really are to
be committed, even if technically possible.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2021-10-14 22:38:21 | Re: psycopg3 transactions |
| Previous Message | Daniel Fortunov | 2021-10-14 11:08:11 | Re: Re: psycopg3 transactions |