Databases
StackOverflow2013
Postsdbo
POWhen is Rails Eager loading by default for all association a good idea?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhen is Rails Eager loading by default for all association a good idea?
    primarykey
    data
    text
    <p>At which point is good to make all queries on a large project to eager load all of the objects associations?<br> Let me explain the background of this question.<br> Currently i am working on a project that has become quite complex in terms of models and associations. I started to check the server logs and saw that some views were taking some time to load because of the nested objects contained in the queries.<br> So i begin to refactor some of these queries to something like this: </p> <pre><code>@process = current_account.processes.query(params) </code></pre> <p>To this:</p> <pre><code>@process = current_account.processes.includes(:messages, :parts, :people).query(params) </code></pre> <p>The result was pretty good. In some views i was able to reduce the view render time and activerecord query time by 70%.<br> Man i was happy, so i decided to make more. But after this decision, i started to notice that not all places i refactored the code, the changes were good. In fact, there were queries that became slower.<br> To explain a little more about the problem i have a model like this: </p> <pre><code>class Process has_many :anotations has_many :publications has_many :movimentations has_many :reunions has_many :profiles ... </code></pre> <p>And each one of these nested models inside <code>process</code> <code>belongs_to :user</code> that created it like this:</p> <pre><code>class Anotation belongs_to :user class Reunion belongs_to :user class Profile belongs_to :user </code></pre> <p>And it go on.<br> In my <code>show view</code> of <code>process</code>, there is several tabs that display <strong>all</strong> of these nested objects and the name of the user that has added it to the current process.<br> With a query like this: </p> <pre><code>@process = current_account.processes.query(params) </code></pre> <p>It was performing kinda slow. So i tried something like this: </p> <pre><code>@process = current_account.process.includes(:anotations, :publications, :movimentations, :reunions, :profiles, :messages).query(params) </code></pre> <p>This has made me gain speed on the view rendering, but in activerecord, the the time to retrieve these objects have increased significantly. And it raised to the skies when i eager loaded the <code>user</code> object inside of all nested models of <code>process</code> like this: </p> <pre><code>@process = current_account.process.includes({:anotations =&gt; [:user]}, {:publications =&gt; [:user], etc...).query(params) </code></pre> <p>Well, refactoring the design of the app to behave differently with these associations is not going to happen, so i ask the question again.<br> At which point is good to make all queries on a large project to eager load all of the objects associations?<br> Any tips/best practices/experience on the subject would be gladly appreciated.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USMurifoX
    1. USMurifoX
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhen is Rails Eager loading by default for all association a good idea?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POWhen is Rails Eager loading by default for all association a good idea?
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI suggest a title like "When is Rails Eager loading by default for all association a good idea?"
      singulars
      1. POWhen is Rails Eager loading by default for all association a good idea?
      1. USlulalala
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload