>
> I'll open a ticket about the docs later today.
https://code.djangoproject.com/ticket/21134
> Let me know if you think it can be improved.
>
That looks nice and explicit to me.
I'm OK with trying to to raise exceptions when making a query and
> get_rollback returns True. I'm not sure
Oh dear, I just posted using the wrong Google account!
Short version:
ticket here: https://code.djangoproject.com/ticket/21134
Possible patch for raising exceptions when using broken transactions here:
https://github.com/RichardOfWard/django/commit/cb46c75db275db59b54511c090286255bd9cc46d
There
>
> So you don't think that "one step of an atomic operation failing" is
> reason to fail the atomic operation? Doesn't sound intuitive to me.
>
...
>
The concept of an "atomic" operation, even outside the context of DBMSs, is
> pretty much the consistent throughout CS.
>
> If you are expect
Thanks for the explanations. I wasn't aware that particular difference
between PostgreSQL and MySQL (I've not done much with PostgreSQL).
Perhaps I could have been clearer in my original post: Ansii is right about
silence... when I call my_func the transaction.atomic decorator rolls back
the tr
We're building a site that needs to use transactions, and have been doing
so against the 1.6 beta as 1.6 is nearly out and we thought it would be
easier to use the new transaction api, but we came across an unexpected
problem.
Basically if you catch an IntegrityError and 'recover' from it, the
