thanks On Tue, Jul 14, 2015 at 4:51 PM, Will Bryant <[email protected]> wrote:
> Search for has_one and has_many on api.rubyonrails.org. > > > On 15/07/2015, at 11:49 , gerbdla <[email protected]> wrote: > > Can someone provide a link to the area of the Rails API or documentation > you are discussing. > > On Tue, Jul 14, 2015 at 4:43 PM, Will Bryant <[email protected]> > wrote: > >> Personally I find the double meaning of #reload a bit confusing for >> singular associations, I would expect record.association.reload to reload >> the current instance of the target object, but record.association(reload: >> true) to reload the association itself. The behavior is different if the >> associated object has changed, for example if the record matching a has_one >> has changed. >> >> In general I think it’s a bad idea for singular association proxy objects >> to intercept any instance methods. So I wouldn’t want the has_many >> associations to do it either, for consistency. >> >> >> On 15/07/2015, at 11:26 , Prem Sichanugrist <[email protected]> wrote: >> >> I already asked a question about refactoring `record.associations(true)` >> -> `record.associations(reload: true)` here: >> https://groups.google.com/forum/#!topic/rubyonrails-core/f756F2DLuG0 >> >> However, Eugene raises an interesting question in the PR ( >> https://github.com/rails/rails/pull/20883#issuecomment-121419119) that >> it might actually make sense to just deprecate the support for >> `record.associations(true)`, and asks user to do >> `record.associations.reload` instead. >> >> I think it make sense, but I want to hear how people think first. >> Internally, it actually does the same thing because the current association >> reader code actually calls `#reload` internally as well. >> >> So, do you think it's a good idea to just deprecate and later remove the >> support for `record.associations(true)` instead? >> >> Thanks, >> Prem >> >> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
