2013/9/19 Anssi Kääriäinen <[email protected]> > There is a definite disparency about what the code does and what the docs > say: > """ > If the block of code is successfully completed, the changes are committed > to the database. If there is an exception, the changes are rolled back. > """ > > If an exception is catched inside the block, then there should be no > rollback. >
I'm not following you; as far as I can tell, that's what the docs say and what the code does. With PostgreSQL you can't continue to use the transaction, but in other > databases you can. > You... may... might... Truth be said, you shan't. > For these other databases allowing use of the transaction, yet still > rolling back it later on seems to be a footgun - why are you allowed to > continue to use the transaction if a rollback is going to happen anyways? > Allowing a transaction to proceed after a statement has failed is: - stupid if the transaction is allowed to commit — you would end up with a successful transaction where not all statements have executed, which is exactly the situation transactions are designed to prevent! - useless if it isn't allowed to commit. That's why PostgreSQL forbids it. That's also what the SQLite docs say: http://www.sqlite.org/lang_transaction.html "It is recommended that applications respond to the errors listed above by explicitly issuing a ROLLBACK command." Extracting the same information from the MySQL and Oracle docs is left as an exercise for the reader. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
