On 09/19/2013 04:52 PM, Anssi Kääriäinen wrote: > After some investigation it turns out that this isn't about > IntegrityErrors at all. Instead the problem is that inside @atomic block > Model.save() uses @atomic(savepoint=False) internally. And > @atomic(savepoint=False) forces the outer atomic block to roll back if > errors > happen. > > If I recall correctly there is transaction.set_rollback(False) which > can be used to remove forced rollback. > > In general, there are three ways to respond to errors inside transactions: > 1. allow usage of the TX (MySQL, SQLite etc), allow user to decide > commit/rollback > 2. forbid usage of the TX (PostgreSQL), force it to be rolled back. Actually you can use subtransactions in postgresql if you want to manage failed queries yourself
BEGIN; <do something>; SAVEPOINT sp1; <do something that fails>; ROLLBACK TO SAVEPOINT sp1; <do something else>; COMMIT: this will commit <do something>; and <do something else>; while rolling back the failed <do something that fails>; you can read more on this in http://www.postgresql.org/docs/9.1/static/sql-rollback-to.html Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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.
