Well suppose 2 people are collaborating on an item. The first person through a web client sees a value as "pending". The 2nd person through a different non web client posts a change, that is only picked up by delayed_job, modifies that value from "pending" to "done" and before_filters are involved that trumps the second person's status changes as the first person never knows anything about the new status change that has occurred underneath.
What exactly does "config.threadsafe!" do? And what did "ActiveRecord::Base.allow_concurrency = true" ever do or was intended to do? Thanks -Chris On Thu, Nov 18, 2010 at 5:54 PM, Simon Russell <[email protected]> wrote: > I'd say you probably don't want to do this; even if it did work, which > it doesn't (basically by design) ... what's the problem you're trying > to solve? > > On Thu, Nov 18, 2010 at 17:47, Chris Mayan <[email protected]> wrote: > > Hello, > > I've done a lot of bing searching on this (perhaps I should try googling > > instead...) with no luck, so perhaps the oceania crew can help as I seem > to > > have a complete misunderstanding of how Rails Object-Relational Mapping > is > > supposed to work: > > Question: How on earth do you make Active Record model objects be multi > > thread / multi process safe, so that when an attribute is changed in one > > process (such as from a delayed job) whilst another process (such as a > user > > / web server process which has loaded / mapped the same db row in > question > > as an AR model object), access the attribute, will automatically uses the > > new modified attribute value... _without_ having to call model.reload > > manually? > > (i.e. I would like Rails in the background to automatically call the > > model.reload when it detects that another process has modified any part > of > > the underlying model's DB row mapping, which is more desirable then > calling > > model.reload programatically before every access as that seems just > > insane...) > > Is this possible or have I misunderstood how rails does ORM? > > So a concrete example: > > Assume you have an AR model "ARModel" with tables ar_model and a string > > attribute "attr" which has a default of "unchanged". > > 0. Open 2 terminals > > 1. Start ./script/consoles in each terminal > > 2. Terminal_1: >> tst_ar_model = ARModel.find(1) > > 3. Terminal_2: >> tst_ar_model = ARModel.find(1) > > 4. Terminal_1: >> tst_ar_model.attr > > "unchanged" > > 5. Terminal_2: >> tst_ar_model.attr > > "unchanged" > > 6. Terminal_1: >> tst_ar_model.attr = "something different" > > 7. Terminal_1: >> tst_ar_model.save! > > 8. Terminal_1: >> tst_ar_model.attr > > "something different" > > 9. Terminal_2: >> tst_ar_model.attr > > "unchanged" > > 10. Terminal_2: >> tst_ar_model.attr_changed? > > False > > > > # What would it take for this to reflect the updated attribute value > > "something different" automagically? > > Of course it works if you call in Terminal 2 tst_ar_model.reload; > > tst_ar_model.attr... but it seems rather nuts to have to call this on > every > > attribute access everywhere! > > I have tried config.threadsafe! (and it's > > deprecated config.action_controller.allow_concurrency = true) > > I've even tried on a longshot attr_will_change! ... > > I am working with Rails 2.3.5 > > Is there something else I need to set or have I completely misunderstood > > something? I understand that the 2 AR model objects are 2 separate > objects, > > but being mapped to the same underlying db table entry, should update > > concurrently I would have thought, or, at least know that the underlying > > table object has changed and is dirty via _changed? ... > > Thus shouldn't Rails ORM when you declare threadsafe mode detect that > when > > an underlying DB table entry has changed, ensure that every invocation of > an > > attribute access will know that it has been changed or is dirty and force > a > > reload (or a partial one if it is smart enough to detect only a certain > > field change?) > > Thanks for your help :) > > -Chris > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby or Rails Oceania" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<rails-oceania%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/rails-oceania?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<rails-oceania%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en.
