OK, so what about the has_one case? Say Project has_one :manager, and project.manager is already loaded (which did a "SELECT * FROM managers WHERE project_id = ?"), will project.manager.reload do another "SELECT * FROM managers WHERE project_id = ?", or will it do a "SELECT * FROM managers WHERE id = ?”.
To match the has_many I would expect the former, and sometimes we need this behavior if this is the only way to force the association to be looked up again (whereas currently we can do project.manager(true)). But because the object returned by project.manager looks like it is just a plain record instance, I’d expect #reload to behave like the query, a regular find(id). Especially if I call reload(:lock => true). It seems a big ambiguous what the behavior would be for has_one, which makes me think the original project.manager(:reload => true) is clearer - and then reload on the target of a belongs_to or has_one should always just reload that instance, not load a potentially different record. Do you agree? > On 16/07/2015, at 23:59 , DHH <da...@loudthinking.com> wrote: > > project.documents.reload.first would reload the documents association, then > grab the first entry in that array – not trigger another find(id). Like > calling #load, but ignoring whether it had already been loaded. > > On Thursday, July 16, 2015 at 12:53:31 AM UTC+2, will.bryant wrote: > So are you saying project.documents.reload.first would redo the query to find > the associated record, or would do a find(id) to reload the current instance? > > >> On 16/07/2015, at 01:08 , DHH <da...@loudthinking.com <javascript:>> wrote: >> >> I'd prefer to see us move to a single API, and IMO the trade-offs for >> #reload alone fits the bill. There's no contract saying that a singular >> object from has_one/belongs_to and a collection like has_many has to behave >> the same. In fact, I think it'd be strange to think that it should. A single >> string and an array of strings do not behave the same. >> >> So project.documents.reload.first makes perfect sense to me as reloading the >> documents collection, then grabbing the first one. >> projects.owner.reload.name <http://projects.owner.reload.name/> makes sense >> to me as reloading the owner record itself, then fetching the name (if we >> don't already return self from Record#reload, we should). >> >> -- >> 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 <javascript:>. >> To post to this group, send email to rubyonra...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/rubyonrails-core >> <http://groups.google.com/group/rubyonrails-core>. >> For more options, visit https://groups.google.com/d/optout >> <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 rubyonrails-core+unsubscr...@googlegroups.com > <mailto:rubyonrails-core+unsubscr...@googlegroups.com>. > To post to this group, send email to rubyonrails-core@googlegroups.com > <mailto:rubyonrails-core@googlegroups.com>. > Visit this group at http://groups.google.com/group/rubyonrails-core > <http://groups.google.com/group/rubyonrails-core>. > For more options, visit https://groups.google.com/d/optout > <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 rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
