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