I remember looking at optimistic locking before I started to write this thing. I dismissed it because optimistic locking was used for two requests that enter memory at about the same time. I had a need for that same behaviour that persists across controller requests. Which optimistic locking doesn't do easily.
When I got around to extracting my application code into a plugin, I had completely forgotten about optimistic locking. I am completely amenable to either reworking things so hooking into optimistic locking instead of attempting to replacing it. Thanks for pointing that out. Referencing Optimistic Locking definitely makes the documentation cleaner. It almost makes me want to change the name of the plugin, to reference Optimistic Locking, something like optimistic locking extension. But I'm hesitant to do so, because it deals with so much more than that. Emery On Dec 18, 12:29 pm, Matt Jones <[email protected]> wrote: > The underlying model mechanism appears to have re-invented optimistic > locking (by checking updated_at rather than lock_version), but the > view code stuff looks like it might be useful... > > --Matt Jones > > On Dec 17, 8:21 am, Emery Finkelstein <[email protected]> > wrote: > > > Greetings, > > > I was hoping to get some feedback on a plugin I wrote. > > > The plugin is called conflict_warnings and is currently available from > > my github repository athttp://github.com/EmFi/conflict_warnings > > -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
