Allow returning values from transactional functions

[waw-google]

Somebody asks in the Slack:

Question about spanner python APIs, specifically transactions.
In a read-write transaction, is it possible to return the updated
value without hitting the database again?

let's say I have the following transaction (pretty much the example from the docs)

    second_album_result = transaction.read(
            table='Albums', columns=('MarketingBudget',),
            keyset=second_album_keyset, limit=1)
    second_album_row = list(second_album_result)[0]
    second_album_budget = second_album_row[0]
    second_album_budget += 10000000
    transaction.update(table=mytable, columns=('MarketingBudget'),
                        keyset=second_album_keyset, values=[(second_album_budget)]
                    )  
    return second_album_budget
database.run_in_transaction(f)

is the return at all possible?

I believe that this is currently not possible in the Python library, because when you pass a closure to run_in_transaction, the return value always gets ignored, and it just returns the commit timestamp.

However this is possible in the Cloud Spanner Java library, and being be able to return whatever you want from the body of a transactional function in the case that a transaction successfully commits is extremely useful.

[bjwatson]

@vkedia @lukesneeringer This sounds useful, but IIUC it sounds like it could be done post-Beta since changing database.run_in_transaction(f) from returning nothing to returning something is not a breaking change.

[lukesneeringer]

It is technically breaking because we do return the commit timestamp, but given that the commit timestamp is pretty useless, I am inclined to agree.

[bjwatson]

Thanks, @lukesneeringer. A meaningless breaking change seems fine for a Beta->GA fix, but we want to avoid any breaking changes post-GA. So before GA we need to:

• fix this for real,
• remove the useless commit timestamp return value, or
• turn the return value into a dict to allow for future expansion (which seems like it might be over-engineering for this use case).

[bjwatson]

Nevermind, just saw that you fixed this for real. Thanks, @lukesneeringer!

[tseaver]

@lukesneeringer FWIW, the major use for the committed timestamp is in setting up subsequent snapshots using request_timestamp.