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