acts_as_list query

rubyonrails-talk
1

Ben wrote:

When moving an item around within the list, shouldn't EVERY item have its optimisitc locking field updated? Currently, only the item that is moved has its optimisitc locking field updated, but every item has its position field changed so surely they too should have their optimistic locking fields updated?

Does it matter? AR operations tend to be transactional...

Best,

2

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 acts_as_list functionality.

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.

3

I'm having a similar problem. My acts_as_list model is a collection of items (lines) belonging to another model (tickets). I expected the lines with a changed position and the ticket to have the version incremented once I save the parent ticket. But nope. The optimistic locking seem to be completely bypassed. The good message is that I could tell a changed collection from a changed ticket version if only the ticket version was updated as it should. But changing th line order or even adding a new line is not recognized as a ticket change, i.e. ticket.save does not get the version incremented.

As a workaround I could manually update a timestamp in tickets before doing the ticket.save which appears to work. Bit I'm looking for a better solution.

Have you found out anything?

Hans