feature request - return transaction object from transaction context manager

[RmStorm]

It would be useful if the transaction context manager returned it's underlying transaction. The use case I have specifically is that I'm running some tests and it's nice to wrap the entire test in a transaction and rollback, what I have in mind is in pytest a structure like:

async with conn.transaction() as transaction:
    yield conn
    await transaction.rollback()

currently the __aenter__ method doesn't return anything so this obviously doesn't work which means I have to use a try/finally block like so:

transaction = conn.transaction()
await transaction.start()
try:
    yield conn
finally:
    await transaction.rollback()

I can imagine that there are other usecases where it's useful to have access to the transaction in a contextmanager. I see that the transaction has a _managed attribute which explicitly disallows this kind of behaviour. What is the reasoning and is it possible to change this? I would be happy to contribute a PR if someone can explain the problem to me.

[elprans]

Well, the entire purpose of the context manager is to provide a contract: queries inside it are guaranteed to execute inside a transaction, and the transaction is terminated when the block is exited. Exposing manual control over the transaction breaks this contract.

I don't see why explicit transaction operations are any worse in the scenario you're describing. You can make your own context manager easily:

import contextlib

@contextlib.contextmanager
async def ephemeral_transaction(conn):
    """A transaction block that always rolls back."""

    transaction = conn.transaction()
    await transaction.start()
    try:
        yield
    finally:
        await transaction.rollback()

# use `async with ephemeral_transaction(conn)`
# in place of `async with conn.transaction()`

[dmig-alarstudios]

I agree with @RmStorm -- having context manager "out of the box" would be nice.

There is nothing wrong with explicit transaction usage, it's just another way of writing code providing more control. And context-managed transactions (same for connections) are just syntax sugar.

I implemented "emphemeral_connection" in my project -- just for convenience. And I'd be happy to see that supported by the library.

[RmStorm]

After a little more thinking I actually agree with @elprans. When I was trying to get hold of the context managed transaction it just seemed a little strange that I couldn't, like an oversight, but as @elprans said this is actually essential for the contract of the context manager to be guaranteed.

Like, what kind of behaviour should occur when a user opens a transaction, calls commit or rollback manually inside the context manager and then executes more queries? Should the context manager throw an error? Silently open a new transaction? The original transaction is gone after rollback or commit is called so there is no clear and intuitive answer here. It's better to keep it as is and keep the transactions fully managed by the contextmanager and in our cases (@dmig-alarstudios) we should just write a little helper or manage the transaction explicitly.

[dmig-alarstudios]

@RmStorm the answer is simple: there should be no API available to manually commit or rollback for the context-managed transaction.
There is a similar case with an explicit transaction: try to use a transaction object after commit/rollback -- you'll get an exception.