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?
I’ve created a drag and drop interface on a list of items that allows
for the items to be moved about to change their position. Whilst one
user can do this, another user can insert an item into the queue
causing a concurrency issue. The problem is this can’t be detected
using normal methods because none of the other items in the queue have
had their optimisitc locking field updated.
I can only assume there is reason that no one else has raised this as
an issue in the past, so I’d be very happy to be enlightened as why.
Thoughts and comments much appreciated.
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.
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…
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.