On 24 Apr 2008, at 10:25, Aliaksey Kandratsenka wrote:
> > У Чцв, 24/04/2008 у 10:04 +0100, Frederick Cheung піша: >> I stumbled across this today: >> >> def find_initial(options) >> options.update(:limit => 1) unless options[:include] >> find_every(options).first >> end > Several month ago I asked same question. I didn't searched history, > but > I guess it's artifact of some very ancient times. > > It works perfectly without this (actually, with :include it always > fetches whole result set and cuts it in memory, which is stupid). Pretty much what I thought. I can't quite think how I'd write a test to verify that it's not doing this though. Fred > > > Our local version of rails has this turned off for almost year now. > And > has it long before new :include implementation landed. So it's safe to > kill this. I hadn't yet time to post a patch for this though. >> >> And I can't think why the special casing of include is necessary. >> Maybe there was a time when :include didn't do the right thing, but >> for at least some time :include has handled this properly, and so any >> one doing Foo.find :first, :include => [...] is inadvertently making >> rails and the db do a lot more work than they think? >> Is this just a relic or is there some reason I missed ? >> >> Fred > > -- > Aliaksey Kandratsenka <[EMAIL PROTECTED]> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
