…Cool! We have an App\Repository\StarshipRepository object. Go check out this class: src/Repository/StarshipRepository.php. First, if you're curious how Doctrine knows this class is the repository for the Starship entity, jump into src/Entity/Starship.php. Ah, the #[ORM\Entity] attribute…

…query, in this case, our homepage() method. One bummer is that DQL isn't that pretty! Luckily, Doctrine has a "query builder". This thing is awesome: instead of writing the DQL string manually, we build it with an object. Back in our homepage() method, replace…

…edges that pop up along the way. And along the journey, we’ll tackle one of the biggest ecosystem shifts: upgrading Doctrine to take advantage of PHP 8.4’s native lazy proxies - goodbye generated proxy classes, hello simpler, faster magic. Whether you’re maintaining…

…on our homepage only lists incomplete starships, so we need to find a completed one. In your terminal, run: symfony console doctrine:query:sql 'SELECT slug, status FROM starship' lunar-marauder-1 is a completed ship. Copy the slug, and back in the app, visit…

…null. But that's not allowed, thanks to the nullable: false. Clear those 50 rows with: symfony console doctrine:query:sql "DELETE FROM starship_part" And run the migration again: So, how do we go about linking a StarshipPart object with its Starship? Buckle up…

…this course, you’ll learn how to: Install and configure the Symfony Form component Build form types with Maker and map them to Doctrine entities Understand the difference between Form and FormView Render forms and fields using Twig’s helper functions Use form_start(), form…

…our good friend: Foundry. Remove the manual code, then anywhere, say: StarshipPartFactory::createMany(100): And try the fixtures: symfony console doctrine:fixtures:load Uh-oh! starship_id cannot be null in starship_part. This traces all the way back to StarshipPartFactory, down in the defaults…

…not technically required - good luck cleaning the bathroom without them! - I like to keep them out of defaults() and set them where we're using StarshipFactory. Next, we'll learn how to JOIN across ManyToMany relationships. Once again, Doctrine handles the heavy lifting for us.

… I like to work with objects whenever possible. Fortunately, Doctrine gives us a simple way to improve this situation: we query for the data we want... but tell it to give us an object. First, we need to create a new class that will hold…

…fortuneCookies|length. In PHP land, we're calling the getFortuneCookies() method on Category. But until now, Doctrine has not yet queried for the FortuneCookie data for this Category. However, as soon as we access the $this->fortuneCookies property, it magically makes that query, basically saying: Give…

…s as boring as SQL queries can get. I used fortune_cookie for the table name because I know that, by default, Doctrine underscores my entities to make table names. Now that we have the query string, we need to create a Statement with $stmt…

…a database perspective, in order to update our WHERE clause to include WHERE fortune_cookie.fortune = :searchTerm, we first need to JOIN to the fortune_cookie table. And that is what we're going to do in Doctrine... except with a twist. Instead of…

… Anywhere inside here, add a new private function called addFortuneCookieJoinAndSelect(). This will accept a QueryBuilder object (make sure you get the one from Doctrine\ORM - the "Object Relational Mapper"), and let's call it $qb. This will also return a QueryBuilder. The next step is…

…validation, voters, and more. That's all good stuff. But, so far, all of our #[ApiResource] classes have been Doctrine entities. And that's fine! But as your API starts to look different from your entities, making that work adds complexity: serialization groups, extending normalizers…

…to count them... isn't the greatest thing for efficiency. If you find yourself in this situation, you can tell Doctrine to be clever with how it loads the relation. Go into the Category entity and find the OneToMany relationship for $fortuneCookies. At the end…

…ObjectTranslator, we have this todo waiting for us. There's a couple ways we can approach this. One way is to directly modify the properties on the object. But since this is a Doctrine entity, it'll be marked as modified. If you unintentionally flush…

…reference With no arguments. This lists all the loaded bundle's, and their configuration key (or extension alias). DoctrineBundle, alias doctrine, DoctrineMigrationsBundle, alias doctrine_migrations. Here's our bundle: ObjectTranslationBundle, alias object_translation. Hmm, I'd like to prefix it with symfonycasts, like the Tailwind…

…and look at src/Factory/LockDownFactory.php. I'm not going to talk too much about these factory classes: we already cover them in our Doctrine tutorial. But this class will make it easy to create LockDown objects, even setting createdAt to a random DateTime…

…darn it, let's yolo this thing and try to! Head over to UserApi, say provider, and point to CollectionProvider (the one from Doctrine ORM). Let's see what happens! At the browser, go to the endpoint directly - /api/users.jsonld. And... we get an…

…you guessed it, Zenstruck! composer require zenstruck/messenger-test --dev Cool! This messenger-test library adds a special Messenger transport called test. We'll still use Doctrine by default, but now open up config/packages/messenger.yaml. Uncomment the async transport, which uses MESSENGER_TRANSPORT…