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.

Reply via email to