Charles Forcey's Profile

Comments by Charles Forcey

One more quick discovery/question. With the second method, I was getting spurious locking errors added to base on creation. It turned out acts_as_list and other such plugins intercept the create process and perform some quick saves to get things in the right place. Not sure I completely understand, but I needed to pass the validation if nothing was in the changes array:

ruby

# app/models/item.rbdefhandle_conflictif@conflict || updated_at.to_f > original_updated_at.to_f
# Commented out because of ability to submit again and overwrite previous value# @original_updated_at = nil # acts_as_list and other items update the position and cause spurious conflicts during creationif changes.empty?
@conflict = falseelse@conflict = true
errors.add :base, "Snap! Someone signed up for this just a moment ago. Pick something else?"
changes.each do |attribute, values|
errors.add attribute, "has just been reserved. Cancel to reload sheet."endendendend

This got my simple creation action up and running again. Thanks for this great episode and any insights on whether this is a short sighted fix. Charles

Thanks so much as always! There is an episode for nearly every thing I want to do! Amazing!

Using the second method, I had a behavior with a remote form that I wanted to pass by the group. I got the first validation error just fine. If I hit submit again, however, the old value would pass the validation the second time and overwrite the value that was protected the first time around.

In other words, the conflict was not detected because @original_updated_at was set to nil and the object reloaded the new timestamp and passed the update right through. If I comment out the @original_updated_at = nil line, I get the behavior I want -- a durable block on any updates to that record.

Does this make sense? What was the value of setting @original_updated_at to nil in the code? Thanks for any advice you might have! Charles