I like this approach. :include should definitely preload, and people should
have to use :joins and :left_joins when they need them all in the same
query.
What would :right_joins do though? You need a left record to load
associations of, otherwise how would you get to the right objects?
Regarding making people explicitly specify the required joins to put
conditions on the associations, if I understand you correctly, I think this
would tend to mean that you end up with numerous copies of your basic
foreign key-based join conditions throughout the codebase, which is not very
DRY.
IMHO when people want to load associations with extra conditions, what
they're really saying is that they want a subset - for which they should
ideally be adding a named_scope on the associated model and somehow telling
Rails to load that scope only.
For example, instead of:
Lunch.find(:all, :include => :pies, :conditions => {:pies => {:steak =>
true}})
as it is currently, or
Lunch.find(:all, :joins => ["LEFT JOIN pies ON pie.lunch_id =
lunches.idAND steak = ?", true])
which is my interpretation of what you're saying below (please correct me if
not), I would like some way to say
Lunch.find(:all, :include => :"pies.steak")
where Pie defines
named_scope :steak, :conditions => {:steak => true}.
However, it's hard to think of a good syntax that shows what scope we want
to be loaded, and in any case I don't think we have loaded-ness for scopes
yet as we do for associations, so there'd be a number of things that would
need to be changed to make that kind of scheme work - it doesn't sound like
an easy approach.
So currently we're stuck with defining extra associations (Lunch.has_many
:steak_pies as well as the original has_many :pies). I'd love a way to get
around that, other suggestions welcome!
Will
On Tue, Jun 16, 2009 at 9:57 PM, Pratik <[email protected]> wrote:
> Ideally I'd like to fix how :include works. I see :include as a pure
> optimization step. Lack or presence of it should only make things
> slower/faster and in no way change the way things work. My ideal fix would
> be :
>
> - Make :include *always* use preload strategy unless the required data set
> is explicitly loaded
> - Introduce :left_joins and :right_joins keys to the finder. Title says it
> all
> - Make user explicitly specify the required joins if they want to put
> conditions on the associations
> - For all the associations specified in :include, check if the required
> dataset has already been loaded by :*joins. If not, preload.
>
> Thoughts ?
>
> On Mon, Jun 15, 2009 at 11:34 PM, dasil003 <[email protected]> wrote:
>
>>
>> Yeah I might give it a shot. I'm a little hammered at work right now,
>> but the code in question has been pretty stable for a while and I
>> think it'll be reasonably easy to implement :strategy option. I'm
>> also happy to collaborate on Fred's work if he's interested... I have
>> some use for some detached type of preloading.
>>
>> One thought I had about :strategy => :preload is that compared to the
>> current hacky approach it's a bit less flexible, because it doesn't
>> let you mix and match. Given that drawback, I wonder if its even
>> worth complicating the API. Maybe officially
>> making :preload_associations public and documenting it would be worth
>> it?
>>
>>
>>
>> On Jun 15, 1:53 am, Michael Koziarski <[email protected]> wrote:
>> > > C) giving access to the Preload strategy explicitly
>> >
>> > > I'm finding a proliferation of Klass.send(:preload_associations,
>> > > foo, :bar) throughout my codebase and it doesn't smell good. The more
>> > > I think about, the more C seems like it might be the only reasonable
>> > > option. Thoughts?
>> >
>> > I've also found myself doing that :preload_associations trick from
>> > time to time and I'm similarly thinking that that shows two things:
>> >
>> > 1) Maybe we should make a nicer way for people to do this (fred cheung
>> > was playing with an array proxy to enable this kind of thing)
>> > 2) We might want to make :strategy=>:preload an option to find.
>> >
>> > I've no idea if :strategy is a good name for the option, but I think
>> > it's probably a good idea to investigate whether the option is
>> > feasible and if it would be useful.
>> >
>> > Care to take a crack at it?
>> >
>> > --
>> > Cheers
>> >
>> > Koz
>>
>>
>
>
> --
> Cheers!
> - Pratik
> http://m.onkey.org
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
