Changes between Initial Version and Version 1 of Ticket #28344, comment 21
- Timestamp:
- Dec 10, 2023, 1:59:33 PM (12 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28344, comment 21
initial v1 20 20 }}} 21 21 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.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. 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. 23 23 24 24 That 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.