Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

Giving same association in :include and :join can result in table being joined twice

#3339

This is a bit of a corner case. Try and wrap your head around it.

If you give the same association in both :include and :join for a find then, as per ticket #528, this forces preloading where eager loading might have otherwise been used... only this is not entirely true! One of AR's limitations is that for any given bunch of associations, it'll try to preload them all but if it can't, it'll eager load them all instead. It does not consider each association for preloading independently.

Consequently, if you give an association in both :include and :join but some other association requires eager loading then both of the associations will be eager loaded. The problem with this is that eager loading doesn't check for any overlap between the given includes and joins and thus the table gets joined twice. ERROR!

This begs the question, why would you specify an association in both when you know it's just going to get eager loaded anyway? In my case, I have a scope where I always do a comparison on some association (join) but only sometimes I want to also include that association (include). Strictly speaking, that scope should not have to determine whether to use :join or :include by itself.

I do like to do the right thing where possible but it's easy to work around in my application and the proper fix could be a little messy. add_joins! needs to filter the given joins based on which associations are being eagerly loaded. But if :join or :include is a hash... hmm. Feel free to tackle this one if you're bored!

Reported by James Le Cuirot · October 6th, 2009 @ 10:10 PM

State: stale
Milestone: none
Assigned to: nobody
Importance: none

Activity

  1. Rishav Rastogi
    Rishav Rastogi

    Hi John,

    Can you give us a more concrete example. And if possible a failing test.

    April 13th, 2010 @ 04:52 AM

  2. James Le Cuirot
    James Le Cuirot

    Sorry for the delay. Here's a failing test case.

    June 6th, 2010 @ 05:18 PM

  3. James Le Cuirot
    James Le Cuirot

    Actually, as my test case highlights, my original description falls short. You don't even need to specify a second association, merely requiring eager loading for the first association is sufficient to trigger the error.

    June 6th, 2010 @ 05:22 PM

  4. James Le Cuirot
    James Le Cuirot
    • Importance changed from to

    Ignore my last comment. Due to a typo in the test case (author vs authors), I confused myself. My original post was correct.

    This has become a bigger problem in my application so I've gone ahead and fixed it. Here is a patch with the fix and an updated test case. I suspect that this will also affect Rails 3 but until I'm ready to migrate my application, I won't have time to look at that. I haven't even looked at the basics of AREL yet.

    September 13th, 2010 @ 04:40 PM

  5. James Le Cuirot
    James Le Cuirot

    I've realised that this fix does not encompass the count method. There is already a fix for a similar problem here as a result of ticket #302. This does not cover my use case though. I've managed to make the two work together but it involves calling add_joins! twice, which is a little odd. I think my newer fix may be able to replace the older one but I'd need to speak to those responsible.

    My question to them is, is it actually necessary to have the separate aliased join? Can we not just avoid the second join in the first place and use the existing one instead? That is what my fix would do. The only caveat is that my code doesn't handle raw join strings, only joins generated through associations.

    September 16th, 2010 @ 04:16 PM

  6. rails
    rails
    • State changed from new to open

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

    April 5th, 2011 @ 01:00 AM

  7. rails
    rails
    • State changed from open to stale

    April 5th, 2011 @ 01:00 AM