Re: [Rails-core] Rails validations and concurrency

2010-11-01 Thread Rodrigo Rosenfeld Rosas
On 31-10-2010 20:21, Aaron Patterson wrote: ... So why don't use use a mutex and wrap your saves with that? I don't see a reason to change AR API for this. ... Ok, I already realized there is no interest from the Rails core team to integrate concurrency features in Rails and maybe I'll creat

Re: [Rails-core] Rails validations and concurrency

2010-10-31 Thread Aaron Patterson
On Sun, Oct 31, 2010 at 09:28:50AM -0200, Rodrigo Rosenfeld Rosas wrote: > On 30-10-2010 15:55, Aaron Patterson wrote: > >... > >>When listening to Yehuda's talk about development on the client > >>side, which was really great by the way, I got really worried when > >>he commented about some Rails

Re: [Rails-core] Rails validations and concurrency

2010-10-31 Thread Xavier Noria
On Sun, Oct 31, 2010 at 6:07 PM, Matt Jones wrote: > > On Oct 31, 2010, at 12:08 PM, Xavier Noria wrote: > >> Perhaps you could even wrap AR::Base#save in your application so that >> if violation of that constraint is detected (assuming the exception >> has information that allows you to do that),

Re: [Rails-core] Rails validations and concurrency

2010-10-31 Thread Matt Jones
On Oct 31, 2010, at 12:08 PM, Xavier Noria wrote: > If one cares about this edge case, I think the best approach is the > one we use for model IDs: let the database take care of it. Set a > UNIQUE constraint, and deal with it in the application. > > Perhaps you could even wrap AR::Base#save in y

Re: [Rails-core] Rails validations and concurrency

2010-10-31 Thread Xavier Noria
If one cares about this edge case, I think the best approach is the one we use for model IDs: let the database take care of it. Set a UNIQUE constraint, and deal with it in the application. Perhaps you could even wrap AR::Base#save in your application so that if violation of that constraint is det

Re: [Rails-core] Rails validations and concurrency

2010-10-31 Thread Allen Madsen
I might be wrong in understanding the problem, but I believe I would use transactions to solve the problems you're describing. I don't see the need to manage locks manually. Allen Madsen http://www.allenmadsen.com On Sun, Oct 31, 2010 at 7:28 AM, Rodrigo Rosenfeld Rosas wrote: > On 30-10-2010

Re: [Rails-core] Rails validations and concurrency

2010-10-31 Thread Rodrigo Rosenfeld Rosas
On 30-10-2010 15:55, Aaron Patterson wrote: ... When listening to Yehuda's talk about development on the client side, which was really great by the way, I got really worried when he commented about some Rails validations not being concurrent-safe nor even thread-safe. While I can understand it

Re: [Rails-core] Rails validations and concurrency

2010-10-30 Thread Aaron Patterson
On Sat, Oct 30, 2010 at 12:56:53PM -0200, Rodrigo Rosenfeld Rosas wrote: > I'm finally back to Vitória, after a great time in RubyConfBR, even > though I've been target of jokes from Aaron Patterson regarding > Rspec questions due my questions to David Chelimsky in a non-related > talk from him. B

[Rails-core] Rails validations and concurrency

2010-10-30 Thread Rodrigo Rosenfeld Rosas
I'm finally back to Vitória, after a great time in RubyConfBR, even though I've been target of jokes from Aaron Patterson regarding Rspec questions due my questions to David Chelimsky in a non-related talk from him. But that's ok, it was fun and I deserved it :) When listening to Yehuda's tal