Re: psycopg2: proper positioning of .commit() within try: except: blocks
Am Mon, Sep 09, 2024 at 01:48:32PM +1200 schrieb Greg Ewing via Python-list: > That code doesn't inspire much confidence in me. It's far too > convoluted with too much micro-management of exceptions. > > I would much prefer to have just *one* place where exceptions are > caught and logged. I am open to suggestions. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: psycopg2: proper positioning of .commit() within try: except: blocks
Am Mon, Sep 09, 2024 at 01:48:32PM +1200 schrieb Greg Ewing via Python-list: > That code doesn't inspire much confidence in me. It's far too > convoluted with too much micro-management of exceptions. It is catching two exceptions, re-raising both of them, except for re-raising one of them as another kind of exception. What would you doing differently and how ? > I would much prefer to have just *one* place where exceptions are > caught and logged. There's, of course, a top level handler which logs and user-displays-as-appropriate any exceptions. This is code from a much larger codebase. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: psycopg2: proper positioning of .commit() within try: except: blocks
On 2024-09-08, Greg Ewing wrote: > On 8/09/24 9:20 am, Karsten Hilbert wrote: >> 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. > > That seems wrong to me. I would have thought the commit should only > be attempted if everything went right. > > What if there's a problem in your code that causes a non-SQL-related > exception when some but not all of the SQL statements in the > transaction bave been issued? The database doesn't know something > has gone wrong, so it will happily commit a partially-completed > transaction and possibly corrupt your data. > > This is how I normally do things like this: > >try: > do something > .commit() >except: > log something > .rollback() > > Doing an explicit rollback ensures that the transaction is always > rolled back if it is interrupted for any reason. What if there's an exception in your exception handler? I'd put the rollback in the 'finally' handler, so it's always called. If you've already called 'commit' then the rollback does nothing of course. -- https://mail.python.org/mailman/listinfo/python-list
Re: psycopg2 positioning of .commit() (Posting On Python-List Prohibited)
On 2024-09-09, Lawrence D'Oliveiro wrote: > On Mon, 9 Sep 2024 09:13:40 - (UTC), Jon Ribbens wrote: >> On 2024-09-08, Lawrence D'Oliveiro wrote: >>> On Sun, 8 Sep 2024 11:03:21 - (UTC), Jon Ribbens wrote: What if there's an exception in your exception handler? I'd put the rollback in the 'finally' handler, so it's always called. If you've already called 'commit' then the rollback does nothing of course. >>> >>> In any DBMS worth its salt, rollback is something that happens >>> automatically if the transaction should fail to complete for any >>> reason. >>> >>> This applies for any failure reason, up to and including a program or >>> system crash. >> >> If it's a program or system crash, sure, but anything less than that - >> how would the database even know, unless the program told it? > > The database only needs to commit when it is explicitly told. Anything > less -- no commit. So the Python code is half-way through a transaction when it throws a (non-database-related) exception and that thread of execution is aborted. The database connection returns to the pool, and is re-used by another thread which continues using it to perform a different sequence of operations ... ending in a COMMIT, which commits one-and-a-half transactions. -- https://mail.python.org/mailman/listinfo/python-list
Re: psycopg2 positioning of .commit() (Posting On Python-List Prohibited)
On 2024-09-08, Lawrence D'Oliveiro wrote: > On Sun, 8 Sep 2024 11:03:21 - (UTC), Jon Ribbens wrote: >> What if there's an exception in your exception handler? I'd put the >> rollback in the 'finally' handler, so it's always called. If you've >> already called 'commit' then the rollback does nothing of course. > > In any DBMS worth its salt, rollback is something that happens > automatically if the transaction should fail to complete for any reason. > > This applies for any failure reason, up to and including a program or > system crash. If it's a program or system crash, sure, but anything less than that - how would the database even know, unless the program told it? -- https://mail.python.org/mailman/listinfo/python-list
Re: psycopg2 positioning of .commit() (Posting On Python-List Prohibited)
Am Mon, Sep 09, 2024 at 10:00:11AM - schrieb Jon Ribbens via Python-list: > > The database only needs to commit when it is explicitly told. Anything > > less -- no commit. > > So the Python code is half-way through a transaction when it throws > a (non-database-related) exception and that thread of execution is > aborted. The database connection returns to the pool, and is re-used > by another thread which continues using it to perform a different > sequence of operations ... ending in a COMMIT, which commits > one-and-a-half transactions. Right, but that's true only when writable connections are being pooled, which should be avoidable in many cases. Any pool worth its salt should rollback any potentially pending transactions of a connection when it is given back that pooled connection. Unless explicitely told not to. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: psycopg2 positioning of .commit() (Posting On Python-List Prohibited)
Am Mon, Sep 09, 2024 at 10:00:11AM - schrieb Jon Ribbens via Python-list: > So the Python code is half-way through a transaction when it throws > a (non-database-related) exception and that thread of execution is > aborted. The database connection returns to the pool, How does it return to the pool ? Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B -- https://mail.python.org/mailman/listinfo/python-list
Re: psycopg2 positioning of .commit() (Posting On Python-List Prohibited)
On 2024-09-09, Karsten Hilbert wrote: > Am Mon, Sep 09, 2024 at 10:00:11AM - schrieb Jon Ribbens via Python-list: >> So the Python code is half-way through a transaction when it throws >> a (non-database-related) exception and that thread of execution is >> aborted. The database connection returns to the pool, > > How does it return to the pool ? It's just any circumstance in which a bit of your code uses a database "cursor" (which isn't a cursor) that it didn't create moments before. -- https://mail.python.org/mailman/listinfo/python-list
Re: psycopg2 positioning of .commit() (Posting On Python-List Prohibited)
On 2024-09-09, Lawrence D'Oliveiro wrote: > On Mon, 9 Sep 2024 10:00:11 - (UTC), Jon Ribbens wrote: >> On 2024-09-09, Lawrence D'Oliveiro wrote: >>> The database only needs to commit when it is explicitly told. Anything >>> less -- no commit. >> >> So the Python code is half-way through a transaction when it throws a >> (non-database-related) exception and that thread of execution is >> aborted. The database connection returns to the pool ... > > The DBMS connection is deleted. How does that happen then? -- https://mail.python.org/mailman/listinfo/python-list
