Eager-loading and custom selects and/or query execution

[MoritzLost]

Is it possible to combine eager-loading with a custom select and/or query execution?

Take this template that uses lazy eager-loading for news_categories:

{% set news = craft.entries().section('news').all() %}
{% for news_entry in news %}
    {% set categories = news_entry.news_categories.eagerly().all() %}
    {# … #}
{% endfor %}

But actually, I only need the title of the news categories, so I could use this:

{% set categories = news_entry.news_categories.select('title').column() %}

But of course this results in an N+1 problem. I tried combining this with eagerly() to get the best of both worlds:

{% set categories = news_entry.news_categories.eagerly().select('title').column() %}

But the amount of queries used stays the same compared to the previous snippet, so I don't think this is supported?

• Is it possible to use (lazy) eager-loading with custom selects and/or query executions?
• If not, is this possible with regular (non-lazy) eager-loading? If
• If not, is there a rule of thumb for what to prefer? I'm leaning towards using eager-loading to reduce the query count, and only use optimized queries without eager-loading for large result sets where the memory footprint might become too large to handle?

[brandonkelly]

It’s only possible to eager-load (normally or lazily) entire elements, not individual values.

I’d stick with your first example. Less queries, simpler/more future-proof code, and better cachability. (By accessing category.title, a cache invalidation tag will be registered for the category, so any surrounding {% cache %} tags, etc., will be cleared whenever the category is updated.)

[brandonkelly]

You’d likely get better performance nowadays using |map(c => c.title), and that would register a cache tag.

[mmikkel]

Good to know, thanks @brandonkelly!

[MoritzLost]

@brandonkelly Got it, thanks for the explanation!

I'm also surprised about this difference between column and map. I thought that executing the query inside the {% cache %} tag is sufficient to register the cache dependencies, is that not correct? In other words, if I have the query above inside a cache tag and only use |column('title') and don't access any other properties, no cache dependency will be registered for those categories?

That's actually a somewhat hefty drawback. I use column a lot because it's more expressive, so that's something to be aware of.

The documentation on the {% cache %} tag implies that executing a query is all that's needed for cache dependencies to be registered:

Your template caches will automatically clear when any elements (entries, assets, etc.) within the tags are saved or deleted.

Maybe this should be clarified? Or would it be possible to add the cache dependencies to the column filter?

[brandonkelly]

Sorry, you’re absolutely right @MoritzLost, if the categories are queried within {% cache %} tags, the element query itself will also register cache invalidation tags.

[MoritzLost]

@brandonkelly Thanks for the clarification, Brandon! I was worried I'd have to fix that in a bunch of projects 😅