On 9/7/24 14:20, Karsten Hilbert wrote:
Am Sat, Sep 07, 2024 at 02:09:28PM -0700 schrieb Adrian Klaver:
Right, and this was suggested elsewhere ;)
And, yeah, the actual code is much more involved :-D
I see that.
The question is does the full code you show fail?
The code sample you show in your original post is doing something very
different then
what you show in your latest post. At this point I do not understand the exact
problem
we are dealing with.
We are not dealing with an unsolved problem. I had been
asking for advice where to best place that .commit() call in
case I am overlooking benefits and drawbacks of choices.
The
try:
do something
except:
log something
finally:
.commit()
cadence is fairly Pythonic and elegant in that it ensures the
the .commit() will always be reached regardless of exceptions
being thrown or not and them being handled or not.
Elegant is nice, but correct is better:)
It is also insufficient because the .commit() itself may
elicit exceptions (from the database).
Yeah with Serializable that is part of the package:
"While PostgreSQL's Serializable transaction isolation level only allows
concurrent transactions to commit if it can prove there is a serial
order of execution that would produce the same effect ..."
Boring and repetitive and safe(r):
try:
do something
except:
log something
try:
.commit()
except:
log something
I eventually opted for the last version, except for factoring
out the second try: except: block.
I'm not following, if you do that then you won't have a commit.
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
--
Adrian Klaver
adrian.kla...@aklaver.com
