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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
