... Except... that won't quite work. Why? The CollectionProvider from Doctrine executes the query and returns the results. So all we would be able to do is take those results... then hide the ones we don't want. That's ...

... Doctrine failed because we never told it to persist the new User object. Though... that's not the point: the point is that we don't want a new User! We want to grab the existing owner and update its username. By the way, to ...

... our Doctrine tutorial. But since this isn't on production, we can cheat and just to turn the database off and on again. To do that run: symfony console doctrine:database:drop --force ...

... called BooleanFilter that we'll use now and another called SearchFilter that we'll use in a few minutes. Pass this BooleanFilter - the one from ORM, since we're using the Doctrine ORM - because we want to allow the user ...

API Platform works by taking a class like DragonTreasure and saying that you want to expose it as a resource in your API. We do that by adding the ApiResource attribute: Right now, we're putting this above a Doctrine ...

... is that our API did return a list of all of the DragonTreasures we currently have, which is just this one. So in just a few minutes of work, we have a fully featured API for our Doctrine entity. That is cool. Copy the ...

... actually have Doctrine installed in this project, so instead of the EntityManager, let's require LoggerInterface $logger... and I'll again add private in front to turn that into a property: Then, down in buildCharacter ...

... doctrine:migrations:list you'll see that it recognizes both migrations and it knows that it has not executed the second one. To do that, run: symfony console doctrine:migrations:migrate Doctrine is ...

... be super easy. To start, remember when the Doctrine recipe asked us if we wanted Docker configuration? Because we said yes, the recipe gave us docker-compose.yml and docker-compose.override.yml files. When Docker boots ...

... go to any question... it says "Updated By", "Null". Our goal is to set that field automatically when a question is updated. A great solution for this would be to use the doctrine extensions library and its "blameable ...

... not required: it does allow null... which is not what we want. But fixing this is easy: ask Doctrine to generate one more migration: symfony console make:migration This is really ...

... must be an int, string given. This is cool. When the deserializer does its work, it first tries to figure out what type the field should be, which we know it does in a number of different ways, like reading Doctrine ...

... know what type title will be. And... that's no surprise! When we serialize a CheeseListing entity, API Platform can use the Doctrine metadata above the title property to figure out that it's a string: But in this case ...

... difference is that the apply() method has different arguments than filterProperty()... which makes sense because that method was all about querying via Doctrine. Before we start filling this in, go to src/Entity ...

... we added a bunch of built-in filters to allow users to search and filter the results: But what if the built-in filters aren't enough? What if we need to add some custom filtering logic? Let's do that next by first creating a custom filter for a Doctrine entity and later creating a custom filter for our DailyStats resource.

When an API resource is a Doctrine entity like CheeseListing, life is good! We get tons of things for free, like pagination, access to a bunch of pre-built filters and one time I swear I got free pizza. But... these ...

... /daily-stats.jsonld and refresh... there are a lot of items here. Since we're not using Doctrine, we no longer get pagination for free. If we need it, we have to add it ourselves.

... already a unique identifier: we're only going to have one DailyStats per day: How do we tell API Platform to use this property as the identifier? In Doctrine, it happens automatically thanks to the @ORM\Id annotation ...

... made to /questions/new. Click the little token string on the right to jump into the full profiler for that request! Go to the "Doctrine" tab and... bam! Cool! It even wraps the INSERT in a transaction. Remember this trick ...

... library instead. Google for "Zenstruck Foundry" and find its GitHub Page. Foundry is all about creating Doctrine entity objects in an easy, repeatable way. It's perfect for fixtures as well as for functional tests where ...