…not available in the prod environment. That's fine for us - this is a development tool - and it keeps the prod environment a little smaller. Anyways, this bundle gives us a new console command - doctrine:fixtures:load. When we run that, it'll look for …

…the route should be /api/programmers/{nickname}/tagline. To be super hip, add an @Method annotation: we know this should only match PUT requests: Like before, type-hint the Programmer argument so that Doctrine will query for it for us, using the nickname value. And…

…a few minutes! To create this cool system, we need to understand a bit about annotations. Every annotation - like Table or Entity from Doctrine - has a class behind it. That means we need a Link class. Create a new directory called Annotation. Inside add a…

… This is all we need to use Pagerfanta. In the controller, start with $adapter = new DoctrineORMAdapter() - since we're using Doctrine - and pass it the query builder. Next, create a $pagerfanta variable set to new Pagerfanta() and pass it the adapter. On the Pagerfanta…

…as the default. Once we do that, we can setup the test environment to use a different database name. Open config.yml and copy the doctrine configuration. Paste it into config_test.yml to override the original. All we really want to change is dbname…

…what a wonderfully trained function: Let's save this! Since we'll need the EntityManager a lot in this class, let's add a protected function getEntityManager(). Use getService() with doctrine.orm.entity_manager. And since I love autocomplete, give this PHPDoc: Now $this->getEntityManager()…

…means we have an easy way to clear data. Create a new private function called purgeDatabase(). Because we have the Doctrine DataFixtures library installed, we can use a great class called ORMPurger. Pass it the EntityManager - so $this->getService('doctrine')->getManager(). To clear things out…

…s an awesome error: This is what it looks like when you mess up your DQL. Doctrine does a really good job of lexing and parsing the DQL you give it, so when you make a mistake, it'll give you a pretty detailed error…

…That's different from SQL, where selecting all the fields from a joined table will give you more fields in your result. Here, addSelect() just tells Doctrine to fetch the FortuneCookie data, but store it internally. Later, when we access the FortuneCookies for a Category…

…which works via a listener to kernel.controller, grabs the id off of the request attributes, queries for a Post object via Doctrine with that id, and then adds a new request attribute called post that’s set to that object: // Summarized version of ParamConverterListener…

…a lot more interesting. You can already see where our controller is called, and under the controller you can see the Twig template and even some Doctrine calls being made. Before and after that, there are a lot of event listeners - you notice a lot…

…files, and the same DoctrineFixturesBundle that we were talking about before. This is a really nice combination because it's going to mean that we can still run our normal php app/console doctrine:fixtures:load. But after that, instead of writing raw PHP code…

… So let’s finish this page. It should be fairly straightforward: we’re going to use Doctrine to query for all the posts and then pass them into a template: /** @Route("/posts") / public function indexAction() { } Now, notice that my template name does not have any…

…and it doesn't! I messed up some syntax. Anytime you see the Doctrine\Common\Annotations T_CLOSE_PARENTHESIS type of thing, this is a syntax error in your annotation. I'm missing a comma between my arguments. Let's try that one more time…

…Update your database schema. The easy, but maybe dangerous way is with the schema update console command: php app/console doctrine:schema:update --force Why dangerous? Let’s say you rename a property from name to firstName. Instead of renaming the column, this task may…

…the router service. So how can we get the router service inside EventReportManager? You know the secret: dependency injection. Add a second constructor argument and a second class property: // src/Yoda/EventBundle/Reporting/EventReportManager.php // ... use Doctrine\ORM\EntityManager; use Symfony\Component\Routing\Router; class…

…mind trick ... I mean auto-complete the use statement for me. It’s lazy, but it almost always works: // src/Yoda/EventBundle/Reporting/EventReportManager.php // ... use Doctrine\ORM\EntityManager; class EventReportManager { } If you’re not too comfortable with this, don’t worry. This is optional…

…we don’t extend anything and we don’t magically have access to this Doctrine object. The code inside EventReportManager is dependent on this “doctrine” object. Well, more specifically, it’s dependent on Doctrine’s entity manager. The fix for our puzzle is to “inject…

…that we show 1 attending means that the database relationship was stored correctly. We can prove it by querying for the join table: php app/console doctrine:query:sql "SELECT * FROM event_user" Yep, we see one row that links our user to this event.…

…better than nothing. But first, update your test database for our latest schema changes: php app/console doctrine:schema:update --force --env=test We need this because we configured our project in episode 2 to use an entirely different database for testing. ./bin/phpunit -c app/