2014-10-01 9:21 GMT+02:00 Florian Apolloner :
> Imo, this is mainly useful to rollback if no error occurred! The other use
> of this feature might work but is quite dangerous imo.
>
If you really know what you are doing, it might be possible to use it
safely while taking advantage of a database's
On Wednesday, October 1, 2014 6:58:28 AM UTC+2, Anssi Kääriäinen wrote:
>
> Django does allow to continue the transaction if you explicitly choose
> to do so. After handling the error, you must use set_rollback[1]. This
> is useful for those rare cases where you want to continue after error in
>
On Wednesday, October 1, 2014 6:58:28 AM UTC+2, Anssi Kääriäinen wrote:
>
> Django does allow to continue the transaction if you explicitly choose
> to do so. After handling the error, you must use set_rollback[1]. This
> is useful for those rare cases where you want to continue after error in
>
On Wed, 2014-10-01 at 14:31 +1000, Curtis Maloney wrote:
> This is primarily a function of the DBMS. When your operations cause
> a DB-level error, the DB needs to roll back the transaction to clean
> up.
This depends on the database. On PostgreSQL, after any error the
transaction (or savepoint)
This is primarily a function of the DBMS. When your operations cause a
DB-level error, the DB needs to roll back the transaction to clean up.
If you don't, you're operating on an unknown state.
Django can not control this beyond wrapping the "risky" operation in a
transaction.
Consider -- exact
Hello there,
I have recently updated to django 1.7, from 1.5 and one of the main changes
I had to do was to replace all deprecated transaction.commit_manually to
transaction.atomic, so far so good.
After this, I have found out that if an IntegrityError or DatabaseError
exception happen inside
