Rails core - Oct 2007 - Re: Looking for comments on a rails patch, lazy association instantiation)

Thanks to a great suggestion by Josh Susser.  I''ve spent the past two
days completely re-working the code I submitted in the eariler patch.

The new patch; http://dev.rubyonrails.org/ticket/10012
accomplishes the same results, but with a much better api.

The earlier patch added a new option for use with :include which named
associated AR classes not to be eagerly loaded.  This negative
specification was awkward.

At Josh''s suggestion, the new patch extends the values acceptable to
the existing :joins option.
If a string it used things will work as before.  If not, the values
take the same form as values for :include, i.e. symbols, hashes, and
arrays of symbols and hashes.  These are used to construct a join
clause for the sql query, and the same code used to process the
results for the :include option, patched to be aware of these new
active record joins,  instantiates the result objects, stripping out
the extra attributes from the join, so that the results are writable
(unlike those returned from :joins with a string value.

This allows you to add tables to a query for use in the conditions,
but not instantiate unneeded associated objects when they will not
(all) be needed.  In addition since this generates a regular inner
join rather than the left outer join generated by :include, less data
may be returned to be processed in cases where there are records with
missing associated records.

I look forward to feedback.

On 10/24/07, Rick DeNatale <rick.denatale@gmail.com>
wrote:
> Prompted by some discussion on rails-talk last week,  I worked up a
> patch to add an option to ActiveRecord::Base#find which allows
> associations to be :included for purposes of the where clause, but
> defers instantiating the included association objects.
>
> The use case is where there are a large number of association rows
> returned by the query, the vast majority will not be used since they
> are only being used to select a small set of root objects.
>
> Here''s the ticket with the patch:
> http://dev.rubyonrails.org/ticket/9923

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Oct 28, 12:43 pm, "Rick DeNatale" <rick.denat...@gmail.com>
wrote:
> Thanks to a great suggestion by Josh Susser.  I''ve spent the past
two
> days completely re-working the code I submitted in the eariler patch.
>
> The new patch;http://dev.rubyonrails.org/ticket/10012
> accomplishes the same results, but with a much better api.
>
> The earlier patch added a new option for use with :include which named
> associated AR classes not to be eagerly loaded.  This negative
> specification was awkward.
>
> At Josh''s suggestion, the new patch extends the values acceptable
to
> the existing :joins option.
> If a string it used things will work as before.  If not, the values
> take the same form as values for :include, i.e. symbols, hashes, and
> arrays of symbols and hashes.  These are used to construct a join
> clause for the sql query, and the same code used to process the
> results for the :include option, patched to be aware of these new
> active record joins,  instantiates the result objects, stripping out
> the extra attributes from the join, so that the results are writable
> (unlike those returned from :joins with a string value.
>
> This allows you to add tables to a query for use in the conditions,
> but not instantiate unneeded associated objects when they will not
> (all) be needed.  In addition since this generates a regular inner
> join rather than the left outer join generated by :include, less data
> may be returned to be processed in cases where there are records with
> missing associated records.
>
> I look forward to feedback.
>
> On 10/24/07, Rick DeNatale <rick.denat...@gmail.com> wrote:
>
> > Prompted by some discussion on rails-talk last week,  I worked up a
> > patch to add an option to ActiveRecord::Base#find which allows
> > associations to be :included for purposes of the where clause, but
> > defers instantiating the included association objects.
>
> > The use case is where there are a large number of association rows
> > returned by the query, the vast majority will not be used since they
> > are only being used to select a small set of root objects.
>
> > Here''s the ticket with the patch:
> >http://dev.rubyonrails.org/ticket/9923
>
> --
> Rick DeNatale
Looks good, I''ll check it out.  With the RC fast approaching, I
can''t
guarantee it''ll make it into Rails 2.0.  If anyone is interested in
this, please try it out on your apps and give us feedback.


--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---