I think the first assumption to challenge is that we can have parity between a collection and a single object. I don't think we can or should. An array of strings does not have parity with a single string.
So project.manager.reload will call ActiveRecord::Base#reload, so that's a Manager.find(id) call, not a Manager.find_by(project: x) call. If you absolutely need the latter, you can do project.reload.manager. I've found this to be an exceedingly rare case, though. So I'm find have it be a round-about to get there, and I'm fine not having parity between collection and record. On Thursday, July 16, 2015 at 2:09:22 PM UTC+2, will.bryant wrote: > > 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 <javascript:>> > 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> 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 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. >> To post to this group, send email to rubyonra...@googlegroups.com. >> 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 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. > 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 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.
