API to access the status of a transaction about transaction

[jimfulton]

I'm wondering what the use cases for this are. I have never wanted to interrogate any of this.

[icemac]

@jimfulton I have a Pyramid application with a PostgreSQL backend. After an INSERT I am using transaction.savepoint() to make sure that an IntegrityError is raised immediately. (Otherwise it would occur on the next implicit flush which does not help at all.)
transaction.savepoint() sets the status of the transaction to COMMITFAILED if there was an error.

I catch the IntegrityError and return (not raise!) a custom exception which the front end can handle and display.

pyramid_tm does not check for the status of the transaction but does a transaction.commit() which leads to a long and nested error message which cannot be displayed to the user. But it supports calling a function which can veto the commit (e. g. for 4xx and 5xx status codes.)
Thus I ended writing such a veto function which checks whether the status of the transaction is transaction._transaction.Status.COMMITFAILED to force pyramind_tm to abort the transaction.

Wow, this is complicated.

TL;DR: If the transaction in the status COMMITFAILED (which was set by a failed savepoint) I do not want to commit it at the end of the request as this would fail, too. I have to check the status and then abort it if needed.

[jinty]

On Wed, Apr 05, 2017 at 05:52:37AM -0700, Jim Fulton wrote: I'm wondering what the use cases for this are. I have never wanted to interrogate any of this.

To debug some transaction problems in the past I wrote a WSGI middleware to raise an error/log if there was an open transaction on the current thread.

…

-- Brian Sutherland

[jimfulton]

On Thu, Apr 6, 2017 at 2:56 AM, Michael Howitz <[email protected]> wrote: […]

Wow, this is complicated.

Right. I'm worried about adding to that complexity.

*TL;DR:* If the transaction in the status COMMITFAILED (which was set by a failed savepoint) I do not want to commit it at the end of the request as this would fail, too. I have to check the status and then abort it if needed.

Why do we need commit failed and doomed? Regardless, this feels like an application architecture problem. The whole notion of having these states feels like a safety belt for buggy applications rather than a facility applications should build on. I worry that exposing it will just encourage application hacks. Amongst the choices: - When you catch the integrity error, abort the transaction yourself, begin a new one and return your error response, or - Let the tm tween abort the transaction and have an error handler outside the tween generate the error response. - A variation on this is to catch the error when you do the savepoint and wrap ir another error to provide more context for an error handler.

[jimfulton]

On Thu, Apr 6, 2017 at 4:28 AM, Brian Sutherland <[email protected]> wrote:

On Wed, Apr 05, 2017 at 05:52:37AM -0700, Jim Fulton wrote: > I'm wondering what the use cases for this are. I have never wanted to interrogate any of this. To debug some transaction problems in the past I wrote a WSGI middleware to raise an error/log if there was an open transaction on the current thread.

I can see this. I wonder how this interacts with the recent changes to add an explicit mode.

[icemac]

Am 06.04.2017 um 15:28 schrieb Jim Fulton <[email protected]>: […]

Amongst the choices: - When you catch the integrity error, abort the transaction yourself, begin a new one and return your error response, or

@jimfulton This sounds like a good idea. I was not sure if it would be nice to have a `transaction.abort()` in the model code. But having `transaction.savepoint()` already there it will not make the code worse. As there is no longer a need for the veto function. Thank you for the tip. I’d suggest to close this issue.

[icemac]

Closing as suggested by myself.