Does it matter? AR operations tend to be transactional...
It matters when dealing with concurrency. At the moment, everytime the
queue gets updated as a result of someone moving items around in the
queue or an item being removed from the queue, I use optimisitc
locking to see if the queue has changed state since the last update.
If it has, I inform the user, redraw the queue and then allow them to
continue moving items around. This works great when two users are
moving items around the queue at the same time and I've also got the
problem of items removed from the queue resolved too, however. Another
part of the interface allows an item to be inserted at the top of the
queue (move_to_top). That operation doesn't update any of the locking
columns for any of the other items even though it updates all of their
positions. So now users can continue moving items around the queue and
not know that another item has been inserted. This leads to queue
items with identical positions which rather defeats the point of the
It becomes even more of a problem when that queue is then loaded into
a hash where the position column is the key to the hash, because the
two items with identical positions overwrite one another.
I can't even think of a way to work around the problem, because even
if I check the size of the queue (after adding an item it would be
bigger) it is still possible for the queue size to be the same, as
another item could also have been removed from the queue. I think I'm
going to have to change the acts_as_list for my purposes, to make it
update the locking column for all items on any 'move' operation.
Hence wondering if this should have been the case in the first place.