Answers.Body: <p>Isn't eager loading the wrong idea here, since categories do not have a property anyway, which automatically points to entries assign to this category?</p>
  
  <p>Let's take 2 samples:</p>
  
  <p>Sample #1: behavior like lazy loading (one entry query per category)</p>
  
  <pre><code>{% for category in categories %}
  {% set entries = craft.entries...relatedTo(category)
  {% endfor %}
  </code></pre>
  
  <p>Sample #2: behavior like eager loading (one entry query for all categories)</p>
  
  <pre><code>{% set entries = craft.entries...relatedTo(categories)
  </code></pre>
  
  <p>Now the only trick is to sort the entries in a way that they are easy accessible from each category in the <code>{% for category in categories %}</code> loop.</p>
  
  <p>Or should't Craft automatically cache the loaded categories and therefor make accessing them from the entry fast after having executed the Sample #2 query?</p>
  
  <p>What I mean is that it would not become faster, only more comfortable if this eager loading was possible.</p>
  
  <p>Only ideas...</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-21T22:54:47.347Z
Answers.Text: Can you please tell me how to do the missing step, get each group of entries related to every category? It’s not really possible without further queries, is it? I mean, you got the right set of entries there, but that doesn’t help much if we loose the relations.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-21T23:01:54.770Z
Answers.Text: What do you mean by “categories do not have a property”? The entry to categories relationship was just picked because I though it would illustrate the reverse-relation problem clearly, as categories are usually the target elements. But the issue does actually apply to all element relationships.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-22T06:57:08.080Z
Answers.Text: ad 1: I will try, give me some time
  ad 2: you are right, I just meant that it's a question of comfort and not a question of amount of queries. Coming from the src side of a relation always gives you the property containing the relation, but never from the target side.
Answers.UserDisplayName: Matthias Redl-Mann
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2017-08-21T14:58:38.173Z
Answers.LastActivityDate: 2018-07-21T12:23:51.603Z
Answers.LastEditDate: 2018-07-21T12:23:51.603Z
Answers.UserDisplayName: Matthias Redl-Mann
Body: <p>Is it possible to load reverse related elements? I mean if the elements I’m querying are the target elements?</p>
  
  <p>Example:</p>
  
  <p>I’m setting up a criteria model to get some categories and I also want to load the entries related to each category. I’m using a Categories field, so my categories are the target elements of those relations.</p>
  
  <pre><code>{% for category in craft.categories.group('news').all() %}
      {% set query = craft.entries.relatedTo({
          targetElement: category,
          field: 'myCategoriesField',
      }) %}
  
      {# Oh no, a N+1 query problem... #}
      {% set entries = query.all() %}
  {% endfor %}
  </code></pre>
  
  <p>I could probably do it the other way around, query for the entries and eager load the categories. Then use the <code>group</code> filter to order everything by category. But that approach is awkward and has limitations, e.g. doesn’t play well with pagination.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-05-23T22:44:30.020Z
Comments.Text: Did anything ever come of this?
Comments.UserDisplayName: Mark Busnelli Jr
Tags: <relations><elementcriteriamodel><eager-loading>
Title: Eager loading of reverse related elements?
ThreadText: # Eager loading of reverse related elements?
  
  (Asked by: username_0 on 2016-03-10)
  
  Is it possible to load reverse related elements? I mean if the elements I’m querying are the target elements?
  
  Example:
  
  I’m setting up a criteria model to get some categories and I also want to load the entries related to each category. I’m using a Categories field, so my categories are the target elements of those relations.
  
  ```
  {% for category in craft.categories.group('news').all() %}
      {% set query = craft.entries.relatedTo({
          targetElement: category,
          field: 'myCategoriesField',
      }) %}
  
      {# Oh no, a N+1 query problem... #}
      {% set entries = query.all() %}
  {% endfor %}
  
  ```
  
  I could probably do it the other way around, query for the entries and eager load the categories. Then use the `group` filter to order everything by category. But that approach is awkward and has limitations, e.g. doesn’t play well with pagination.
  
  **Tags:** relations, elementcriteriamodel, eager-loading
  
  > **Comments:**
  > **username_1**: Did anything ever come of this?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-08-21. Score: 1
  
  Isn't eager loading the wrong idea here, since categories do not have a property anyway, which automatically points to entries assign to this category?
  
  Let's take 2 samples:
  
  Sample #1: behavior like lazy loading (one entry query per category)
  
  ```
  {% for category in categories %}
  {% set entries = craft.entries...relatedTo(category)
  {% endfor %}
  
  ```
  
  Sample #2: behavior like eager loading (one entry query for all categories)
  
  ```
  {% set entries = craft.entries...relatedTo(categories)
  
  ```
  
  Now the only trick is to sort the entries in a way that they are easy accessible from each category in the `{% for category in categories %}` loop.
  
  Or should't Craft automatically cache the loaded categories and therefor make accessing them from the entry fast after having executed the Sample #2 query?
  
  What I mean is that it would not become faster, only more comfortable if this eager loading was possible.
  
  Only ideas...
  
  > **Comments:**
  > **username_0**: Can you please tell me how to do the missing step, get each group of entries related to every category? It’s not really possible without further queries, is it? I mean, you got the right set of entries there, but that doesn’t help much if we loose the relations.  
  > **username_0**: What do you mean by “categories do not have a property”? The entry to categories relationship was just picked because I though it would illustrate the reverse-relation problem clearly, as categories are usually the target elements. But the issue does actually apply to all element relationships.  
  > **username_2**: ad 1: I will try, give me some time ad 2: you are right, I just meant that it's a question of comfort and not a question of amount of queries. Coming from the src side of a relation always gives you the property containing the relation, but never from the target side.  
  
  ---
  
  