Changes between Initial Version and Version 1 of Ticket #28344, comment 21


Ignore:
Timestamp:
Dec 10, 2023, 1:59:33 PM (12 months ago)
Author:
Aivars Kalvāns

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #28344, comment 21

    initial v1  
    2020}}}
    2121
    22 it leads to a situation where the object `foo` differs from the now locked database record. That's why I would like to have a single operation to lock the object and refresh the object with the latest "locked" values from DB is valuable. I'm all for something like `refresh_from_db` or `refresh_for_update` to avoid programming errors and reduce number of database operations at the same time.
     22it leads to a situation where the object `foo` differs from the now locked database record. That's why I would like to have a single operation to lock the object and refresh the object with the latest "locked" values. I'm all for something like `refresh_from_db` or `refresh_for_update` to avoid programming errors and reduce the number of database operations at the same time.
    2323
    2424That said, I have objections to RoR way of `obj.lock_for_update` or `obj.with_lock`: it implies that the lock will be released once the block ends, but that is not the case. Once locked, the record will be locked until the main transaction is committed or rolled back. Nested transactions (savepoints) may release locks when rolled back, but it differs between databases: Oracle does not release locks, but Postgres does (IMHO). It looks nice, but it gives the wrong impression of how it works.
Back to Top