…and... we can now see when each droid was assigned. That's it, friends! We've explored the deepest corners of Doctrine relationships, even the elusive many-to-many with extra fields. As always, if you have questions, drop them in the comments below. We…

…This one is pretty common in Doctrine, though not always easy to understand: A new entity was found through the relationship Starship#starshipDroids that was not configured to cascade persist for the entity StarshipDroid. This is a very fancy way of saying we've created…

…but I don't have migrations configured for this project. So in your terminal, run: symfony console doctrine:schema:update --force Before we check out the UI, the bundle has two optional dependencies that I want to install. First: composer require knplabs/knp-time-bundle…

…add a leftJoin(). But we're not going to think about the join table or the database. Nope, focus only on the relationships in Doctrine. So we're joining across s, which is our starship, and droids, the property that has the ManyToMany relationship to…

…database: with a join table. The real magic of Doctrine is that we only need to think about objects. A Starship object has many Droid objects, and a Droid object has many Starship objects. Doctrine handles the tedious details of saving that relationship to the…

…to generate the migration and run it: Go take a peek. No surprises here. So... run it: symfony console doctrine:migrations:migrate And... we've got a shiny new droid table in the database. It's not yet in a relationship with ship, but hey…

…the flush, remove an assignment: $starship->removeDroid($droid1): Reload the fixtures and check out the join table. Only two rows remain! Doctrine removed the row for our removed droid. One final touch on ManyToMany — remember when we discussed owning versus inverse sides of a relationship?…

…in the template looping over the parts, when we reference part.starship, Doctrine has a light bulb moment. It realizes it has the part data, but not the Starship data for this part. So it queries for it. We end up with one query for…

…what's happening: we grab the starships, then as soon as we count ship.parts, Doctrine realizes it doesn't have that data yet. So it fetches all the parts for each ship one by one and counts them. This is a common situation: we…

…ll do our standard double-check to make sure the migration isn't trying to mine bitcoin. Yep, all boring SQL queries here. Run it with: symfony console doctrine:migrations:migrate And it explodes in our face. Rude! But... it shouldn't be too surprising…

…method. All we need is: DragonTreasureFactory::createMany(40) to create a healthy trove of 40 treasures: Let's try this thing! Back at your terminal, run: symfony console doctrine:fixtures:load Say "yes" and... it looks like it worked! Back on our API docs, refresh…

…if statement... like if ship.type == 'freighter', but that would get messy really fast. Instead, let's use Twig template inheritance. Twig Template Inheritance with Doctrine Inheritance, I love it! First, in the templates/starship directory, create a new teaser directory. This will be…

…10 of them cost more than 50,000. What a waste! Could we ask Doctrine to change the query so it only grabs the parts related to the starship where the price is greater than 50,000? Enter the Criteria object. This thing is mighty…

…count($bookings))). Testing time! Pop over to your terminal. To be sure we have a booking that needs a reminder sent, reload the fixtures with: symfony console doctrine:fixture:load Now, run our new command! symfony console app:send-booking-reminders Nice, 1 reminder sent…

…we aren't using migrations. So, we'll just force update the schema. In your terminal, run: symfony console doctrine:schema:update --force Then, reload the fixtures: symfony console doctrine:fixture:load That all worked, great! Next, we'll create a new reminder email and…

…andWhere() is always ok - even if this is the first WHERE clause... and we don't really need the "and" part. Doctrine is smart enough to figure that out. What's wrong with ->where()? Well, if you added a WHERE clause to your QueryBuilder earlier…

…Question: That method properly removes the Answer from Question. But more importantly, it sets $answer->setQuestion() to null, which is the owning side of this relationship... for you Doctrine geeks out there. Ok, try removing "95" again and saving. Hey! We upgraded to an error…

…on. It's subtle, but look at the WHERE clause: s0_.id = ?. This s0_ is an internal SQL table alias Doctrine uses - it's our starship table. I expected this to use our discriminator column, but it's using the id. I guess when…

…sent to be queued. We'll use the Doctrine transport as it's easiest to set up. composer require symfony/doctrine-messenger Back in our IDE, the recipe added this MESSENGER_TRANSPORT_DSN to our .env and it defaulted to Doctrine - perfect! This transport adds…

…you know, doing our real job. I'll hit enter to go down the list one-by-one. First up is Doctrine Bundle: and it's a complex update. It even caused a conflict! Sometimes we might see that a recipe update changes something - like…