…it's a PHP class where the up() method holds the SQL to create our table. What's neat is how this was created: Doctrine compared the current state of our entities to the database and generated the SQL needed to make them match. Wow…

…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…

…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…

…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…

…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…

…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…

…s coming from Doctrine, something about raw field value access... But look at this! A link to a pull request right in the message! Very helpful, I love it! Copy the link and paste it in your browser... This is the Doctrine PR that modified…

…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…

… 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…

…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.

… 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…

…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…

…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…

…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…

…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…

…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…

…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…

…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…

…the item of type UserApi. We already talked about what's happening: the JSON is deserialized into a UserApi object. Good! Then the core Doctrine PersistProcessor is called because that's the default processor when using stateOptions. But... because our UserApi isn't an entity…