Rails - Sep 2010 - acts_as_list query

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.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

i think you should allow position to be null and that every new entry should
be new , im not sure

On Thu, Sep 9, 2010 at 11:15 AM, Ben
<benperry-KuiJ5kEpwI4qdlJmJB21zg@public.gmane.org> 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?
>
> 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.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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

On 10 Sep., 12:28, Ben Perry
<b3npe...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > 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.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.