Hi,
Review would be appreciated on this patch which stops
find returning incorrect results when multi-level STI
models are eagerly loaded:
http://dev.rubyonrails.org/ticket/10624
--
We develop, watch us RoR, in numbers too big to ignore.
--~--~-~--~~~---~--~---
Pratik wrote:
> I've uploaded a patch to optimize eager loading, which changes the
> code to spend less time in ruby -
> http://dev.rubyonrails.org/ticket/10011
>
> The problem is because of following line in
> associations.rb:#construct_associations :
> collection.target.push(association) unles
Gabe da Silveira wrote:
> He means there's no way to do custom eager loading. Namely, a
> find_by_sql (or any find call without :include for that matter) only
> ever instantiates models of a single type. There is a much larger class
> of performance problems that can be solved by allowing ins
Michael Koziarski wrote:
> I'm personally not sold on this particular optimisation technique. I
> think the real problem here is that it's still too hard to load a
> graph of objects out of a find_by_sql call. If that were fixed you'd
> be able to optimise cases like this, without too much comp
Michael Koziarski wrote:
>> Are their other dangers with such a definition that makes
>> you uncomfortable?
>
> I just don't think that the feature justifies adding such strange and
> counter-intuitive syntax. I'm all for adding methods to core classes
> that aid developers, every day. Things l
Ticket 7147, among others, discusses support for restricting
attribute selection for finds that do eager-loading.
A core team member was not enthusiastic about approaches
that required the parsing of :select option SQL, so I've
tried another approach in an attempt to get core team
support for thi
Gabe da Silveira wrote:
> On 8/11/07, *Mark Reginald James* <[EMAIL PROTECTED] wrote:
> 2. :select is used to restrict the size of base model data returned
>
> Unfortunately eager loading ignores the select option.
There's a plugin for this now:
http://rubyforge.org/pro
Trevor Squires wrote:
> 1 - using :include one-level-deep when you are fetching *one*
> toplevel object *and* you are not issuing :conditions on
> the :included tables is *always* (well, I've never found an
> exception) slower.
>
> x = Foo.find(4678. :include => [:incoming_messages, :outgo
Courtenay wrote:
What you mean to say is, no, you shouldn't do it that way :) since
it'll tie up the controller.
I just thought that for something that doesn't take too long,
the simplicity of just adding a "yield" to the action code is
attractive.
You could fork off a process and detach it
Hi,
Is there any interest in allowing controller methods to do
post-response processing? This would be useful where some
time-consuming statistic or index processing should be done
after the response has been sent so as not to delay a response
that does not depend on that processing.
This coul
Is it intended that the AR sum method return nil rather than 0 (int) or
0.0 (float) when no rows match the conditions? This is the result I get
using MySQL.
I can't find any mention of this issue in either Trac or the mailing
list archives, so I'll make up a patch if there's confirmation this is
I wanted to make an ActiveRecord mod that added a "sanitize_html"
function that caused the attributes listed as its parameters to be
automatically stripped of dangerous HTML segments through use of
ActionView::Helpers::TextHelper.sanitize.
It was a bit messy to get working because I had to pull p
12 matches
Mail list logo
