-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle transaction rollbacks #148
Comments
Hey @lukebryant! |
I was thinking this wouldn't work because the context manager would have no way of getting references to all the models that are changed within its scope. Am I missing something, or did you mean that the context manager would take a list of potentially mutating models as arguments? edit: thanks for quick response btw :) |
Yeah you would need to pass these as arguments. Far from ideal for sure... |
Right now, I would at least document the issue and ask people to manually save and restore dirty fields for their affected model in case of rollback. |
Document Issue #148 when using transactions and dirtyfields
Currently, if we do:
This behaviour is problematic, because field in-memory and database values are still different.
It seems like this will be tricky to solve.
We could have a property
uncommitted_dirty_fields
, which we could clear in anon_commit()
signal, but I can't think of a way of settingdirty_fields = uncommitted_dirty_fields
in the case of a rollback, since there is noon_rollback()
signal.edit: If we had some way of uniquely identifying the current transaction (I can't see one in current django api), we might be able set
dirty_fields = uncommitted_dirty_fields
insideget_dirty_fields()
iftransaction_at_time_of_last_save != current_transaction
. Then there'd be some additional complexity from rollbacks inside nested transactions.The text was updated successfully, but these errors were encountered: