From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Daniel Fortunov <postgresql(at)danielfortunov(dot)com>, 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: psycopg3 transactions |
Date: | 2021-10-14 22:38:21 |
Message-ID: | e8dc0835-b2f2-8cc1-fdd1-5994ab1b8582@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On 10/14/21 15:16, Karsten Hilbert wrote:
>> 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.
+1
>
> 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.
If I'm following that option exists:
https://www.psycopg.org/psycopg3/docs/api/connections.html#psycopg.Connection.transaction
force_rollback (bool) – Roll back the transaction at the end of the
block even if there were no error (e.g. to try a no-op process).
>
> Karsten
> --
> GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
>
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Daniele Varrazzo | 2021-10-15 10:56:25 | Re: psycopg3 transactions |
Previous Message | Karsten Hilbert | 2021-10-14 22:16:25 | Re: Re: psycopg3 transactions |