Closed GeyseR closed 3 months ago
It's been a very long time since the change, so I've had to look back over the commit history to answer your question.
You're correct in that setting ATOMIC_REQUESTS=True
doesn't quite restore the original behaviour. ATOMIC_REQUESTS=True
only rolls back the revision and database transaction if the view raises an exception, whereas pre-4.0.0 django-reversion rolled it back on and status code >= 400.
Using ATOMIC_REQUESTS=True
and RevisionMiddleware
is pretty close to the original behaviour. If you want the exact behavior you'll need to go with your option (3).
In general, the advice django
gives with ATOMIC_REQUEST
about it being "inefficient when traffic increases" applies even more strongly to django-reversion
. The best thing to do is to use transaction.atomic()
and reversion.create_revision()
manually where needed.
The 4.0.0 docs section says:
From the description I initially thought that by using the ATOMIC_REQUESTS setting the original reversion middleware will be restored.
But after checking the source code of the reversion package and django itself I think there are several options for the developer: 1) use create_revision decorator or ReversionMiddleware - create revisions automatically for all models changes made in the view. Optionally wrap view(s) in transaction 2) use transaction.atomic or ATOMIC_REQUESTS - wrap view(s) in atomic, handle revisions creation manually 3) write own decorator/middleware to restore the original behavior that rollbacks model changes on status >= 400
Did I get the current state of things right? Should we make the section more clear?