Because what is on memory is a cached version of you association. It is cached to avoid unnecessary queries on the database.
If you want to invalidate the cache you have to tell Rails to do it. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Tue, Feb 19, 2013 at 1:13 PM, ChuckE <[email protected]> wrote: > Thanks for the suggestion, that's what I meant by tucking stuff. My point > is, stuff is already somewhere right in memory, why couldn't it be set > right there? I'm exactly trying to avoid the DB roundtrips and the possible > spaghetti code stemming from such a situation. > > Terça-feira, 19 de Fevereiro de 2013 17:04:50 UTC+1, Rafael Mendonça > França escreveu: >> >> If you want to reload the association cache you can pass true as >> argument. >> >> s.formats(true).select { |f| f.tag == "original" } >> >> Will always get what you want. >> >> Rafael Mendonça França >> http://twitter.com/**rafaelfranca <http://twitter.com/rafaelfranca> >> https://github.com/**rafaelfranca <https://github.com/rafaelfranca> >> >> >> On Tue, Feb 19, 2013 at 12:56 PM, ChuckE <[email protected]> wrote: >> >>> Hi, >>> >>> I came across a certain use case that could need some fine tuning. Let's >>> say I have a song Model. This song is available in many formats. So, the >>> song has_many formats (mp3, flac, ...). The song also has the original >>> where the other might have been generated from. So, the song has_one >>> original. This is my current state of affairs: >>> >>> class Song < ActiveRecord::Base >>> has_many :formats >>> has_one :original, class_name: "Format", conditions: { tag: "original" >>> } >>> end >>> >>> So far, so good. Problem is, now I have my original made available in >>> two different places, and if I update one, it is not reproduced on the >>> other, until I synchronize everything from the database (not to the >>> database). >>> >>> s = Song.first >>> s.formats.select{|f| f.tag == "original" } # original original >>> s.original #original original >>> s.original = Format.create(.... tag: "original") # changed original >>> s.formats.select{|f| f.tag == "original" } # original original (!!) >>> s.reload >>> s.formats.select{|f| f.tag == "original" } # changed original >>> >>> And this sucks, specially when I start playing around with validations, >>> I end up tucking more than I would like to. >>> >>> So the question is: how well could one devise such an association which >>> is contained somewhere else? Something like: >>> >>> class Song < ActiveRecord::Base >>> >>> has_many :formats >>> has_one :original, class_name: "Format", conditions: { tag: "original" >>> },* on: :formats* >>> >>> end >>> >>> And from then on this "has one" would be a proxy to an instance >>> contained in an has_many collection. >>> >>> So, what would speak against such a feature? I'm all hears >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ruby on Rails: Core" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to rubyonrails-co...@**googlegroups.com. >>> To post to this group, send email to rubyonra...@googlegroups.**com. >>> >>> Visit this group at http://groups.google.com/** >>> group/rubyonrails-core?hl=en<http://groups.google.com/group/rubyonrails-core?hl=en> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >>> >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
