Adding new Properties
In our VinylMix entity, I forgot to add a property earlier: votes. We're going to keep track of the number of up votes or down votes that a particular mix has.
Modifying with make:entity
Ok... so how can we add a new property to an entity? Well, we can absolutely do it by hand: all we need to do is create the property and the getter and setter methods. But, a much easier way is to head back to our favorite make:entity command:
php bin/console make:entity
This is used to create entities, but we can also use it to update them. Type VinylMix as the class name and... it sees that it exists! Add a new property: votes... make it an integer, say "no" to nullable.. then hit "enter" to finish.
The end result? Our class has a new property... and getter and setter methods below.
| // ... lines 1 - 9 | |
| class VinylMix | |
| { | |
| // ... lines 12 - 31 | |
| #[ORM\Column] | |
| private ?int $votes = null; | |
| // ... lines 34 - 99 | |
| public function getVotes(): ?int | |
| { | |
| return $this->votes; | |
| } | |
| public function setVotes(int $votes): self | |
| { | |
| $this->votes = $votes; | |
| return $this; | |
| } | |
| } |
Generating a Second Migration
Ok, let's think. We have a vinyl_mix table in the database... but it does not yet have the new votes column. We need to alter the table to add it. How can we do that? The exact same way as before: with a migration! At your terminal, run:
symfony console make:migration
Then go check out the new class.
| // ... lines 1 - 12 | |
| final class Version20220718170741 extends AbstractMigration | |
| { | |
| // ... lines 15 - 19 | |
| public function up(Schema $schema): void | |
| { | |
| // this up() migration is auto-generated, please modify it to your needs | |
| $this->addSql('ALTER TABLE vinyl_mix ADD votes INT NOT NULL'); | |
| } | |
| // ... lines 25 - 31 | |
| } |
This is amazing! Inside the up() method, it says
ALTER TABLE vinyl_mix ADD votes INT NOT NULL
So it saw our VinylMix entity, checked out the vinyl_mix table in the database, and generated a diff between them. It realized that, in order to make the database look like our entity, it needed to alter the table and add that votes column. That's simply amazing.
Back over at the terminal, if you run
symfony console 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 smart enough to skip the first and execute the second. Nice!
When you deploy to production, all you need to do is run doctrine:migrations:migrate each time. It will handle executing any and all migrations that the production database hasn't yet executed.
Giving Properties Default Values
Ok, one more quick thing while we're here. Inside of VinylMix, the new votes property defaults to null. But when we create a new VinylMix, it would make a lot of sense to default the votes to zero. So let's change this to = 0.
Cool! And if we do that, the property in PHP no longer needs to allow null... so remove the ?. Because we're initializing to an integer, this property will always be an int: it will never be null.
| // ... lines 1 - 9 | |
| class VinylMix | |
| { | |
| // ... lines 12 - 32 | |
| private int $votes = 0; | |
| // ... lines 34 - 110 | |
| } |
But... I wonder... because I made this change, do I need to alter anything in my database? The answer is no. I can prove it by running a helpful command:
symfony console doctrine:schema:update --dump-sql
This is very similar to the make:migration command... but instead of generating a file with the SQL, it just prints out the SQL needed to bring your database up to date. In this case, it shows that our database is already in sync with our entity.
The point is: if we initialize the value of a property in PHP... that's just a PHP change. It doesn't change the column in the database or give the column a default value, which is totally fine.
Auto-Setting createdAt
Let's initialize one other field: $createdAt. It would be amazing if something automatically set this property whenever we created a new VinylMix object... instead of us needing to set it manually.
Whelp, we can do that by creating a good, old-fashioned PHP __construct() method. Inside, say $this->createdAt = new \DateTimeImmutable(), which will default to right now.
| // ... lines 1 - 9 | |
| class VinylMix | |
| { | |
| // ... lines 12 - 34 | |
| public function __construct() | |
| { | |
| $this->createdAt = new \DateTimeImmutable(); | |
| } | |
| // ... lines 39 - 115 | |
| } |
That's it! And... we don't need the = null anymore since it will be initialized down here... and we also don't need the ?, because it will always be a DateTimeImmutable object.
| // ... lines 1 - 9 | |
| class VinylMix | |
| { | |
| // ... lines 12 - 29 | |
| private \DateTimeImmutable $createdAt; | |
| // ... lines 31 - 115 | |
| } |
Nice! Thanks to this, the $createdAt property will automatically be set every time we instantiate our object. And that's just a PHP change: it doesn't change the column in the database.
All right, we have a VinylMix entity and the corresponding table. Next, let's instantiate a VinylMix object and save it to the database.
Hello
I somehow messed one of my tables badly, so when I run Symfony console make:migration and all my files are committed (no changes) this migration is generated:
My Questions:
symfony console doctrine:migrations:diffto generate the current SQL and then remove all migrations except the first one, and in the "up" method to add the generated code. However it didn't mention what should one add in the "down" method. Can this approach be used as a way to resolve messed up migrations?