Changes between Initial Version and Version 11 of Ticket #28344


Ignore:
Timestamp:
09/19/2018 05:21:07 AM (2 years ago)
Author:
Jure Erznožnik
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #28344

    • Property Summary changed from Add `for_update=False` to `refresh_from_db()` to Add for_update parameter to Model.refresh_from_db()
    • Property Version changed from 1.11 to master
    • Property Owner nobody deleted
    • Property Triage Stage changed from Unreviewed to Accepted
  • Ticket #28344 – Description

    initial v11  
    1 I have a project where we deal with many financial operations that rely on transactions and row-level locking a lot to guard against race conditions. Unfortunately it's a common pattern for a function to accept an instance of model A, start an atomic block, fetch a new instance of the same row with `select_for_update()`, do a change, call `save()` and then refresh the original instance. It would all be easier if I could just call `instance.refresh_from_db(for_update=True)` and it would save a me a DB roundtrip to refresh the original instance passed (Django ORM does not have a session manager so the old object will not otherwise reflect the changes).
     1I'm investigating this ticket for possible implementation at PyCon UK sprints. Initial thoughts:
     2
     3I like the pattern suggested above:
     4
     5{{{
     6with obj.lock_for_update():
     7    obj.some_attr = 13
     8# Would this be auto-saved at the end of the CM's block?
     9}}}
     10
     11However, this one implies both a transaction and an auto-save to me. So my proposal would be to "decorate" the `lock_for_update()` with two parameters:
     12
     13* `atomic: bool=True`
     14* `auto-save: bool=True`
     15
     16Would this be an acceptable solution?
Back to Top