Okay, yeah, one of those calls can be used each time
I have a situation where the cached data might be stale
(thanks... I hadn't thought of those). But the idea
behind your last sentence is what's bothering me.
It seems to me to be dangerous (misleading at best) not to,
as you say, always have a foreign key modification force a cache
update. Given my understanding, it seems like such a no-brainer
that I figure I must have some fundamental misunderstanding about
rails.
-glenn
Michael Frederick wrote:
Two options I've found:
1. c.parent.reload
2. c.clear_association_cache
Both do what you would imagine. It feels like changing the underlying
id should force this sort of behavior on the next access of the
parent, but it doesn't (yet?).
- Michael
On 10/12/07, Jordan A. Fowler <[EMAIL PROTECTED]> wrote:
Nathan,
That's a class method to reset the column information in the event that it
actually changes. Such as when you've made changes to your schema (like in a
migration) and need to have your ActiveRecord model class to reflect the
correct columns. He's talking about caching on a per-object basis.
I should have a decent response soon...
--Jordan
On Oct 12, 2007, at 10:33 PM, Nathan Colgate Clark wrote:
This might help:
Parent.reset_column_information
http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001034
-N
Glenn Little wrote:
It seems like rails is doing some data caching on objects
that is causing inconsistencies. If you do a lookup through
a belongs-to, that result persists even if you change the foreign
key (on the memory object without yet saving):
parent has-many children
child belongs-to parent
Parent.find(1).surname
=> "Smith"
Parent.find(2).surname
=> "Jones"
c = Child.find(1)
c.parent_id
=> 1
c.parent_id = 2
c.parent.surname
=> "Jones"
Okay, fine. What I wanted. Change has taken
effect. But now:
c.parent_id = 1
c.parent.surname
=> "Jones"
Not what I wanted. The earlier result is cached somewhere.
(I did the original id change from 1 to 2 just to show that
the cached value was *not* just whatever the initial database
value was). It's not a matter of "what's in the db versus
what has not been saved yet". It's more arbitrary. Whatever
value c.parent.surname reports is dependent on when you first
did a lookup, and is "stuck" from then on.
So you get weirdness like this:
c.parent.surname
=> "Jones"
Parent.find(c.parent_id).surname
=> "Smith"
Is this acceptable? If so, how does this not mean I need to ditch the idiom
"c.parent.surname" (nice) in favor of "Parent.find(c.parent_id).surname"
in any of my code where a value *might* have changed and it's possible
I *might* have done accessed through the association since then, and I
haven't saved the child record yet (for good reason, maybe I'm doing this
as part of validation)?
Is there a way to force rails to not use (or mark as out-of-date)
the cached info? A "c.reload" does not work, because my c object
in memory may deliberately have different info than the database,
and the reload would wipe it.
Thanks in advance!
-glenn
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby
--------------------------------------------------------------
Jordan A. Fowler
2621 First Ave Apt 5
San Diego, CA 92103
E-mail: [EMAIL PROTECTED]
Website: http://www.jordanfowler.com
Phone: 406.546.8055
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby
