3 ms·
The example with follower_count shows how to use the +1 technique to do without locking. That's OK IMHO. It's not possible to use that technique when updating o
by pmontra 3y ago
The example with follower_count shows how to use the +1 technique to do without locking. That's OK IMHO. It's not possible to use that technique when updating other type of data. Example
select * from issues where id = 123;
-- do something in app
update issues set status = 'done' where id = 123;
There you can lose a status update if two people happen to work on the same issue at the same time with two different ideas of how to update it.
Or the classic bank account balance update. Both must be solved with a SELECT FOR UPDATE. That should be in the demo page of every ORM, to be sure that people that don't know SQL don't make that kind of mistakes.
- Rapzid 3y ago> The example with follower_count shows how to use the +1 technique to do without locking.. Without explicit pessimistic locking. There are always locks. More guarantees, more locks. That issue example can be tackled with optimistic concurrency controls depending on the constraints. The issue can be checked out with an UPDATE .. WHERE .. RETURNING ..
- deleted 3y ago[deleted]