Doctrine: how to enable eager loading programmatically? - php

Question

Imagine the following situation. You have books:
Book(bookId, authorId, title)
and authors:
Author(authorId, name)
and each book has (for the sake of simplicity) a single author.
By default all associations are configured in lazy mode. So, if I have the scenario, when I first load all books, iterate over the collection and fetch author of each book, I'll perform lots of queries to the database.
$books = $this->getDoctrine()
->getRepository('AppBundle:Book')
->findAll();
foreach($books as $b) {
echo $b->getAuthor()->getName();
}
Can I programmatically ask Doctrine to load authors eagerly for this specific query (not globally via configuration)?
Related: In Doctrine 2 can the Fetch Mode (Eager/Lazy etc.) be changed at runtime?
Related: http://doctrine-orm.readthedocs.io/projects/doctrine-orm/en/latest/tutorials/getting-started.html#list-of-bugs

Answer 1

You can simply mark the association between books and authors as EAGER (versus the implicit default of LAZY) and Doctrine will always load that particular association up front.
This can be accomplished by adding:
fetch=EAGER
to the mapping association.
One potential method to do this at runtime would be to create a Mapped Superclass. The superclass would define your relationships and other parts of your associations (not the relationship you're trying to adjust).
Then, to actually use the class at run time, you could create two other concrete implementations: LazyBook and EagerBook. Depending on your scenario at runtime, you would use one or the other of these concrete implementation entities to construct your associations.
Of course, LazyBook would define your Book -> Author association as a LAZY one (either explicitly or implicitly) and EagerBook would define it as EAGER.
This isn't truly dynamic as you've defined, but it allows you to programmatically determine which association to use at any given time while also self-documenting that it could be either.

Answer 2

One very important thing to understand here, is that Doctrine uses the Data Mapper pattern and not the Active Record pattern (you can find it in the Yii framework for example):
Doctrine 2 is an object-relational mapper (ORM) for PHP 5.4+ that
provides transparent persistence for PHP objects. It uses the Data
Mapper pattern at the heart, aiming for a complete separation of your
domain/business logic from the persistence in a relational database
management system.
The benefit of Doctrine for the programmer is the ability to focus on
the object-oriented business logic and worry about persistence only as
a secondary problem. This doesn’t mean persistence is downplayed by
Doctrine 2, however it is our belief that there are considerable
benefits for object-oriented programming if persistence and entities
are kept separated.
http://doctrine-orm.readthedocs.io/projects/doctrine-orm/en/latest/tutorials/getting-started.html#what-is-doctrine
That essentially means, that entity classes do not know a single thing about how they are persisted to the database. Even though they can have comment type annotations on them, those are just a form of metadata processed by ORM.
In turn that means you can do the very same thing you did with ActiveRecord, but it's now done at just another place. Let's take a look at the difference:
In ActiveRecord-based ORM (like Yii):
$books = Book::model()->with('author')->findAll();
In DataMapper-based ORM (like Symfony/Doctrine):
$books = $this->getDoctrine()->createQueryBuilder()
->select(['b', 'a'])
->from('AppBundle:Book', 'b')
->join('b.author', a')
->addSelect('a')
->getQuery()
->getResult();
Small comment on the later. The query you are building there is not an SQL query, but rather a DQL query (object-query-language employed by Doctrine).
So join/addSelect in here is much like with at the former query just telling ORM engine that you would like to load author at the same query. Particular relation metadata (e.g. column names for both underlying tables) is still defined out there at the entities metadata level.
Syntax (select, from, join) resembles the SQL on purpose, but you shouldn't be confused by it. Here, building the query, you operate ORM entities and not the database columns/tables.