On Mon, Jul 18, 2011 at 5:28 PM, Federico Di Gregorio <federico.digrego...@dndg.it> wrote: > On 18/07/11 11:25, James Henstridge wrote: >> If all adapters that support transactions function like that, then I >> think it would be sensible to require them to raise an error in that >> case. If they don't raise an error, you know that someone somewhere >> is going to write code like the following: >> >> with transaction: >> # do stuff >> with transaction: >> # do more stuff >> >> ... and wonder why things break. > > This can make sense for backends that support check points > (subtransactions). PostgreSQL is an example (even if we don't yet > support checkpoints in psycopg).
While it is definitely possible to simulate some kind of "sub-transaction" through the use of save points, I'm not sure whether it is actually a good idea to magically substitute one for the other. One feature of committing a transaction is that it makes the work has been saved permanently and is available to other connections, which won't be the case with a save point based sub-transaction. If I wrote some code that relied on those semantics (e.g. one that posts a message to another process after completing its work), then it would be an error to call it from within transaction context and I'd want to see an error explaining the fact. There probably are uses where a recursive transaction decorator/context manager might be useful, but I don't think it is necessarily something users would want by default. James. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
